The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for April 1990 (292 messages, 195251 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/04.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 Apr 90 04:30:00 GMT
From:      CSP1DWD@OAC.UCLA.EDU (Denis DeLaRoca  825-4580, 213)
To:        comp.protocols.tcp-ip
Subject:   DNS mess with NIC losing 10.0.0.1 address

Most of the hosts in our local domain didn't take kindly to the NIC
losing its 10.0.0.51 address, they continue to cache that information.
I even found some hosts running Name Servers that think that the NIC
has only what it used to be its Arpanet address?

I am curious as to how much better is the rest of the world doing? I
just checked the DNS over at usc.edu, and it is currently caching the
obsolete NIC entry. The Name Servers over at isi.edu, however, do
reflect the new NIC configuration!

-- Denis

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 90 04:42:30 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with AIX "illegal protocols" ?


>> >From TCP-IP-RELAY@NIC.DDN.MIL  Sat Mar 31 09:52:07 1990
>> Date: Thu, 29 Mar 90 07:09:36 EST
>> From: Marci Kennedy <marci@aretha.franklin.uga.edu>
>> To: TCP-IP%SRI-NIC.ARPA@uga.cc.uga.edu
>> Subject: Re: Problems with AIX "illegal protocols" ?
>> 
>> I don't know, but it is worrisome.  Perhaps you should pass this information
>> on to Kurt Jansen, who's boss is planning to invest heavily in the new
>> RISC (risk?) product from IBM.  Perhaps Schaffer can bring some pressure
>> to bare on the SE IBM group that will have positive repercussions.
>> 
>>                                -- Marci


I fail to see why this is an IBM problem.  Its the HP machine that is
dieing.  Because it doesn't for whatever reason handle an unknown
protocol type properly.  IBM is perfectly free to use an unused code
for whatever.  Sure at some point they should get it registered but
that doesn't make it their problem.  It is HP's and they should
be contacted.

-c
cisco

(former HP employee)

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sun, 01 Apr 90 15:00:22 EDT
From:      "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Problems with AIX "illegal protocols" ?
On Tue, 27 Mar 90 23:37:27 GMT Ralph Nicovich said:
>I can Identify the exact "IP PROTOCOL TYPE" that causes the HP's to
>crash. It is 0x5b (hex) this "type" is not defined in RFC-1010 which
>I believe is the current official document defining "IP PROTOCOL TYPES".

As another reply has indicated, 0x5B is LARP, Locus ARP.  This protocol
type is documented in the newly released "Assigned Numbers" RFC 1060
(available from SRI-NIC as of March 30).
  Lee Varian
  Princeton University
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 90 14:16:53 GMT
From:      zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!linc.cis.upenn.edu!farber@think.com  (David Farber)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: High Schools on the Internet

We, at UPenn, are in the final stages of putting our
local magnet high school of engineering and 
science -- the George Washington Carver High School
in Philadelphia onto the internet via
a spread spectrum radio link operating license free at 
900 mh. 

By the way, the GWC High School is an interesting case of
what can be done to turn the inner city
students onto science and education. They are really
an outstanding example.

Dave
David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele:
215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8192;  Cellular:  302-740-
1198 "The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment." -- R. P. Feynman
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 90 18:51:17 GMT
From:      snorkelwacker!usc!cs.utexas.edu!ntvaxb!kev@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   O where O where did those RFC.PS's go?

         Someone recently asked where the RFC's are.  What I want
         to know is where the POSTSCRIPT-formatted RFCs are?  Are
         there any?  Which ones?  Where?

         Thanks in advance,

         Kevin
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 90 19:00:22 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with AIX "illegal protocols" ?

On Tue, 27 Mar 90 23:37:27 GMT Ralph Nicovich said:
>I can Identify the exact "IP PROTOCOL TYPE" that causes the HP's to
>crash. It is 0x5b (hex) this "type" is not defined in RFC-1010 which
>I believe is the current official document defining "IP PROTOCOL TYPES".

As another reply has indicated, 0x5B is LARP, Locus ARP.  This protocol
type is documented in the newly released "Assigned Numbers" RFC 1060
(available from SRI-NIC as of March 30).
  Lee Varian
  Princeton University

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 90 21:33:58 GMT
From:      pallas!lbert359@uunet.uu.net  (Lee Bertagnolli)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP over 56KB line on 386

A local university is about to get an Internet feed and the system administrator
has suggested that I can also link *my* system through his router.  I am 
running an AT&T 6386 (20Mhz) using AT&T V/386 R3.2 with T2500's.

Questions:  To hook up to Internet, what do I need (hardware, software, etc)?
What do I need to establish communications with the university's router?  
Obviously we can use the Telebits, but are there other alternatives?  For 
instance, since I am only a few miles away, is it feasible to get a 56kb
digital line, and run over V.35 DSU's?  If so, where can I get a board for
my 386 that will support that speed?

Any feedback on this will be greatly appreciated.  Please e-mail responses,
will summarize at a later date...

-- 
+ Lee Bertagnolli                +                      Voice: (217) 544-0270 +
+ Athenanet, Inc.                +                      Data:  (217) 525-9019 +
+ 630 South Pasfield             +             UUCP:  {uunet}!pallas!lbert359 +
+ Springfield, Illinois  62701   +   Internet:  lbert359@pallas.athenanet.com +
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Apr 90 08:57:32 PDT
From:      postel@venera.isi.edu
To:        cire@cisco.com
Cc:        TCP-IP@nic.ddn.mil, marci@aretha.franklin.uga.edu
Subject:   Re: Problems with AIX "illegal protocols" ?

Hi.

Well no one is "perfectly free to use an unused code for whatever".
All protocol codes are to be registered with the IANA.  It turns out
that the code in question is registered (91 = LARP), see RFC-1060 page 8.

However, i'd really like to see an explanation of why any machines crash
when a datagram with a protocol type they didn't know about before comes
along.  Anyone have the story?

--jon.

IANA = Internet Assigned Numbers Authority (contact is JKRey@ISI.EDU).
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 90 02:13:58 GMT
From:      drilex!dricejb@bbn.com  (Craig Jackson drilex1)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Where Has UDP Been Implemented?
In article <939@ftp.COM> jbvb@ftp.COM (James Van Bokkelen) writes:
>In article <28460@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes:
>> On what systems is the UDP datagram currently supported, and who
>> are the vendors who sell the protocol as part of some package?
>
>Get a copy of the "DDN Implementations and Vendors Guide" from the
>people at SRI (ftp from NIC.DDN.MIL or on paper).  Essentially the
>only IP host systems that don't have a user-accessible UDP are
>dedicated terminal concentrators, and all of those that use
>nameservers necessarily contain an internal-use UDP.

There is one system at least which implements TCP but not UDP.  I suspect
there are others because I don't believe that UDP was ever a DDN/
Mil-Spec requirement.

The system which implements TCP but not UDP is the Unisys A-Series.
When they did TCP/IP for the A-Series, they implemented it in terms of 
the native networking for the A-Series, which is called BNA.
BNA is message oriented, and connection oriented.  There was no
existing syntax to express sendto/recvfrom concepts.  Partially because
of that, and possibly because of the lack of the DDN requirement
mentioned above, UDP was not present in the initial implementation.

Needless to say, this has made it hard to implement certain modern
portions of the protocol suite, such as the Domain Name Service.
They haven't--the host table is statically defined at the time
that the CP2000 communications front-end is initialized.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Apr 90 11:14:34 -0400
From:      bzs@world.std.com (Barry Shein)
To:        zrfp0128%awssn3.rus.uni-stuttgart.de@RELAY.CS.NET
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   tftp,anonymous ftp

>In tftp there is nearly no security. An example:
>Everyone in the network is able to read any file that is readable to wourld.
>On UNIX machines that usually includes /etc/passwd. There are
>several programs to analyse /etc/passwd for easy-to-find password.
>(Often such programs use a long list of words found in a dictionary).
>Therefore I think you should run the tftpd only, if you WANT hackers on
>your machine.

The case is overstated, at least on Suns you can run tftpd in secure
mode in which case it chroot's to a specified directory (usually
/tftpboot tho that's settable in /etc/inetd.conf).

If this is done all they can grab is files under that directory, which
can usually be kept harmless easily (boot binaries, some people keep
files needed by X terminals which use tftp there.)

Of course, keeping easy-to-find passwords or using shadow password
facilities out of your system has its advantages also. I would guess a
lot of break-ins (particularly ones that go undetected) are "inside
jobs".

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 90 06:55:35 GMT
From:      zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   tftp,anonymous ftp

In tftp there is nearly no security. An example:
Everyone in the network is able to read any file that is readable to wourld.
On UNIX machines that usually includes /etc/passwd. There are
several programs to analyse /etc/passwd for easy-to-find password.
(Often such programs use a long list of words found in a dictionary).
Therefore I think you should run the tftpd only, if you WANT hackers on
your machine.

Some time ago I heard that tftp is a part of history; that means it was written
for some tests and never taken away after that.
Instead of that my impression is that we have a more general problem:
NEARLY ALL NETWORK SOFTWARE IS FIRST DESIGNED FOR FUNCTIONALLITY WITHOUT
THINKING ABOUT SECURITY.
LATER PEOPLE TRY TO ADD SECURITY AND SOMETIMES HAVE SUCCES.

If you run anonymous ftp in a stupid way you have similar problems.
But with anonymous ftp you have facilities to restrict, what the 
user of anonymous ftp can reach. Therefore anonymous ftp is often 
used for 'ftp-servers' with public domain data.

Nevertheless with anonymous ftp you have the risk of software errors
opening holes. I remember that some time ago such a hole became well known.

Disclaimer: That is only my opinion, may be my employers have other.

Joerg Hertzer
Computer Center University Stuttgart
zrfp0128@awssn3.rus.uni-stuttgart.de

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Apr 90 14:02:09 PDT
From:      postel@venera.isi.edu
To:        snorkelwacker!usc!cs.utexas.edu!ntvaxb!kev@BLOOM-BEACON.MIT.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  O where O where did those RFC.PS's go

Request for Comments are available from the Network Information
Center in the online library at NIC.DDN.MIL.

When an RFC is available in PostScript, the PostScript version is the 
definitive version, however,  a secondary version is available in
ASCII.  The secondary ASCII version may lack figures and the
information encoded in typographic variation (italics, boldface,
etc.).  Since this information often provides esssential context, the
ASCII version is at best incomplete and at worst misleading.  Anyone
expecting to understand this document is strongly encouraged to obtain
the PostScript version.

RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
RFC:RFCnnnn.PS (where "nnnn" refers to the number of the RFC) for the
PostScript version, and RFC:RFCnnnn.TXT for the secondary ASCII
version.  Access with FTP-username ANONYMOUS and FTP-password GUEST.

The NIC also provides an automatic mail service for those sites which
cannot use FTP.  Address the request to SERVICE@NIC.DDN.MIL and in the
subject field of the message indicate the file name, as in "Subject:
SEND RFC:RFCnnnn.PS" for the PostScript version, or "Subject:
SEND RFC:RFCnnnn.TXT" for the secondary ASCII version.

Requests to be added to or deleted from this distribution list should
be sent to RFC-REQUEST@NIC.DDN.MIL.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Apr 90 14:53:17 EDT
From:      Michael A. Patton <MAP@lcs.mit.edu>
To:        LARSON@crvax.sri.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   MX Records
In an ongoing discussion of defaulting MX to use A records:

   Date: Wed 28 Mar 90 11:00:16-PST
   From: Alan Larson <LARSON@crvax.sri.com>

   The present system provides for reasonable defaults, ...

This is a little overstated, I'd say it provides for acceptable fallbacks.

	and reduces the amount of information ... transmitted in the
   DNS in common cases. 

Wrong!  It requires two seperate DNS transfers in the most common case
rather than only one if you do provide the MX.  This can substantially
lengthen the time it takes to make a delivery determination, doubling
it on average.  This can make a significant difference in some mail
delivery systems.

   The current use of an A record implying an MX record is reasonable, and
   should be retained.

Again I feel you are too strong, I'd say that the practice of using an
A record in the face of a lack of MX is acceptable fallback (liberal
in what you accept), but that people should be encouraged to put MX
records in for all hosts (conservative in what you generate).

	    __
  /|  /|  /|  \		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. :-)
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Apr 90 08:55:35 +0200
From:      Joerg Hertzer <zrfp0128%awssn3.rus.uni-stuttgart.de@RELAY.CS.NET>
To:        TCP-IP@NIC.DDN.MIL
Subject:   tftp,anonymous ftp
In tftp there is nearly no security. An example:
Everyone in the network is able to read any file that is readable to wourld.
On UNIX machines that usually includes /etc/passwd. There are
several programs to analyse /etc/passwd for easy-to-find password.
(Often such programs use a long list of words found in a dictionary).
Therefore I think you should run the tftpd only, if you WANT hackers on
your machine.

Some time ago I heard that tftp is a part of history; that means it was written
for some tests and never taken away after that.
Instead of that my impression is that we have a more general problem:
NEARLY ALL NETWORK SOFTWARE IS FIRST DESIGNED FOR FUNCTIONALLITY WITHOUT
THINKING ABOUT SECURITY.
LATER PEOPLE TRY TO ADD SECURITY AND SOMETIMES HAVE SUCCES.

If you run anonymous ftp in a stupid way you have similar problems.
But with anonymous ftp you have facilities to restrict, what the 
user of anonymous ftp can reach. Therefore anonymous ftp is often 
used for 'ftp-servers' with public domain data.

Nevertheless with anonymous ftp you have the risk of software errors
opening holes. I remember that some time ago such a hole became well known.

Disclaimer: That is only my opinion, may be my employers have other.

Joerg Hertzer
Computer Center University Stuttgart
zrfp0128@awssn3.rus.uni-stuttgart.de

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 90 14:43:11 GMT
From:      snorkelwacker!ira.uka.de!fauern!fauern!eckert@tut.cis.ohio-state.edu  (Toerless Eckert)
To:        tcp-ip@nic.ddn.mil
Subject:   looking for information about ARGO
Hi.

I am looking for information about the ISO software developed in the
ARGO project. If i am correctly informed, this is the software
developed jointly by IBM and U of Wisconsin to provide TP4, X.25/CONS
and other OSI networking to bsd type unix, and which is supposed to
be included into 4.4 BSD.

I am especially interested in the X.25 implementation. Someone
knows licensing conditions for the software, is it available at all ?

-- 

Toerless Eckert     Internet: eckert@informatik.uni-erlangen.de
                    X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 90 16:11:53 GMT
From:      csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu  (Robin Goldstone)
To:        tcp-ip@nic.ddn.mil
Subject:   problems installing CMU-TEK MAILSMB
Excuse me if this is a re-post but I don't think my original posting made
it out...

I am having problems installing the MAILSMB portion of CMU-TEK tcp-ip software
(version 6.4) on out VAX 11/750 running VMS 5.2.  I have installed the
major portions of the software (IPDDRIVER, IPACP, NAMSRV, Telnet and FTP)
several months ago and they are all functioning correctly.

Then I attempted to install the mail-related portions of the software
(INET_MAILSHR, MAILSMB, SMTP_SERVER).  INET_MAILSHR and SMTP_SERVER are
functioning correctly.  I can send a message from VMS Mail to an internet
address and it is accepted and queued up in the system mail queue called
GENERIC_MAIL.  Also, I can send a mail message from another internet host
and it is received by the VAX and also queued up in the GENERIC_MAIL queue.
However, I cannot get the MAILSMB delivery symboint to function.  When
I try to fire it up by executing MAILSMB_STARTUP.COM I get the following
message: %JBC-E-SYMDEL, unexpected symboint process termination.

Does anyone know what this means?  The save set that I installed for
MAILSMB was MAILSMB028, though the installation documentation was for
version 027.  I don't know what the difference might be between these
version...

Any help would be appreciated.  Please reply directly to robin@csuchico.edu
if possible.  Thanks.

Robin Goldstone,  Systems Software Specialist
California State University, Chico  Computer Center
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 90 17:48:32 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help: NFS Mounts over `slip' not working
>If the error is in the data block transmitted (for example, the super block)
>rather than the RPC header, you will see a file system error.

Excuse me?  NFS doesn't transmit super blocks over the wire.

If your link scrambles bits in, say, the data in a "write" request or
the reply to a "read" request, what you will see is corrupted data.  If
it scrambles bits in a file name, you will either see a "no such file"
error, or a file handle for a file other than the one you wanted, or,
most likely, no error at all if the operation was a "create" operation.
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 90 22:54:07 GMT
From:      scamp!jrr@mcnc.org  (Joe Ragland)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tftp,anonymous ftp
In article <9004021514.AA26051@world.std.com> bzs@world.std.com (Barry Shein) writes:
>
>>In tftp there is nearly no security. An example:
. . .
>
>The case is overstated, at least on Suns you can run tftpd in secure
>mode in which case it chroot's to a specified directory (usually
>/tftpboot tho that's settable in /etc/inetd.conf).
>
>If this is done all they can grab is files under that directory, which
>can usually be kept harmless easily (boot binaries, some people keep
>files needed by X terminals which use tftp there.)
>
>Of course, keeping easy-to-find passwords or using shadow password
>facilities out of your system has its advantages also. I would guess a
>lot of break-ins (particularly ones that go undetected) are "inside
>jobs".
>
>        -Barry Shein

For what it is worth, a modified version of the Berkeley tftpd, which
solves alot of these security problems, is available via 'anonymous' ftp
from ncnoc.concert.net as file ~ftp/dist/tftpd.tar.   This version 
further restricts tftp to a list of hosts.  From the README file for 
this distribution:

  This directory contains a version of the Trivial File Transfer
  Protocol daemon, tftpd. It is based on a version from Berkeley
  that is copyrighted but freely distributable under the copyright
  rules. I have modified the program to provide options to restrict
  tftp access to a directory tree via chroot and/or by a list of
  hosts allowed access. These restrictions are in addition to the
  standard tftp access restrictions. My changes are public domain,
  so this package is freely distributable under the Berkeley
  copyright rules.


  My changes are intended to compile and run under a variety of
  4.2 BSD and 4.3 BSD based UNIX systems, but I have only tested
  them on systems using the 4.3 BSD syslog facility and multiple-
  address hostent structure. Please let me know of problems with
  this code on other systems.

	Tim Seaver
	MCNC
	tas@mcnc.org

Joe Ragland
CONCERT Network
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue,  3 Apr 90 08:24:05 -0400 (EDT)
From:      Aaron Wohl <aw0g+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil, "cfe+ zaphod. mps.ohio-state.edu!math.lsa.umich.edu!emv"@tut.cis.ohio-state.edu
    (Edward Vielmetti)
Subject: Re: Single domain name/IP address for a group of hosts
In-Reply-To: <EMV.90Mar29121628@duby.math.lsa.umich.edu>
References: <Added.Ia4QNg200UkTMfik4D@andrew.cmu.edu>,
	<EMV.90Mar29121628@duby.math.lsa.umich.edu>

In the andrew distribution overhead/snap2/nametime has a fake domain
name server that does load balancing.  That version gathers its
information with a private proticol, I have a new one that uses SNMP
drop me a note if you are interested.  A fixed berkeley bind that
handles ttl=0 is available (see below).  Drop me a note if you want it
and don't have afs access.

We will anounce on the internet bind and snmp lists list when it is
packaged up and suitable for simple installation.  In the mean time
brave people in a rush should send me mail.
Aaron

Date: Mon,  5 Mar 90 16:14:10 -0500 (EST)
From: Walter Lloyd Wimer III <ww0n+@andrew.cmu.edu>
To: Aaron Wohl <aw0g+@andrew.cmu.edu>
Subject: Re: brekeley load balancing fixes
CC: PC-Daemon <pcs+internal@andrew.cmu.edu>,
    "Charles R. Bartel" <crb+@andrew.cmu.edu>


Aaron,

The file ~ww0n/src/bind/bind.tar.Z is a compressed tarfile of BIND 4.8.1
with CMU load-balancing fixes.  This is the entire source distribution
which should build as-is.  Also included are a diff file of the changes
(for information purposes; the source code already includes the
modifications), a file containing messages from the BIND mailing list
mentioning a few possible bugs (which I've never had a chance to really
check out), and a couple of other infomation-type files.  Let me know if
you have any problems with it.


Walt
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 02:29:41 GMT
From:      mintaka!ogicse!zephyr.ens.tek.com!orca.WV.TEK.COM!richa@think.com  (Rich Ahrendt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:broadcast storm

In article <7422@gouldnl.encore.nl> ted@encore.nl (Ted Lindgreen)
writes:

#In article <9003121734.AA22356@ISIS.U-STRASBG.FR> 
#(Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur 
#Strasbourg FRANCE) writes:
#>
#>Anything I can do? (Stations B and C
#>are mostly SunOS 3.5 , no SUNOS4.0).
#
part deleted
#
#A quick hack to get rid of the ARP's and most ICMP's is to add a
#bogus ARP entry on the systems that don't understand the correct
#broadcast address (in your case 130.79.255.255) to point at some
#non-existing ethernet address:
#/etc/arp -s 130.79.255.255 0.1.2.3.4.5
#or add
#130.79.255.255 0.1.2.3.4.5
#to /etc/rarp.hosts if "/etc/arp -f /etc/rarp.hosts" is invoked
#at boottime.
#
#Of course, this does not help the ancient systems to recognize
#rwho and router messages, but it does help to get rid of your
#broadcast storms.

This might correct the arp's but lot's of ICMP: Destination Unreachable errors
are still around to the non-existent node.  I know my user's should upgrade 
there systems and/or OS to the current revision.  It's not cost effective 
to replace the 100+ older systems that think the broadcast address is X.0.0.0
I thought they would just fade away over time but no they just get handed off
to another user who hasn't yet had a workstation of their own.  Now as the
new faster systems appear on the net the traffic begins to be a concern.

Anyone got any more good ideas, for those of us still having bursts of ICMP
errors?


********************NETWorks**Support**Services***************************
Rich Ahrendt - Visual Systems Group -Interactive Technology Division
   richa@orca.wv.tek.com - Tektronix, Wilsonville, Oregon - USA
********************************NETWorks**************************************
Rich Ahrendt - Visual Systems Group -Interactive Technology Division
     richa@orca.wv.tek.com - Tektronix Wilsonville, Oregon - USA
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 03 Apr 90 10:48:15 PDT
From:      richardt@Legato.COM
To:        lbert359@pallas.athenanet.com (Lee Bertagnolli)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP over 56KB line on 386

I'm told (tho I have yet to test it out) that a standard off the
shelf 386 should be able to keep up with 56k, if you're doing
reasonable buffering.  I am looking into this myself, as I'm
working on building a cheap IP net here in the bay.  I would 
be interested in any special hardware which is recommended to you.

RichardT
Disclaimer:
Legato doesn't want to have anything to do with most of my projects
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 04:34:19 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!bohra!angela@tut.cis.ohio-state.edu  (Angela R. Heal. BSc.)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP


I've had a look in the rfc summary (rfc1000) but I can't locate the rfc that
contains the definition of the SLIP protocol - could someone please give
me a pointer in this direction?

	- Angela

ACSnet:	angela@bohra.oz

-- 

	Angela Heal
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 06:27:46 GMT
From:      snorkelwacker!ira.uka.de!iramu1!nipper@tut.cis.ohio-state.edu  (Arnold Nipper)
To:        tcp-ip@nic.ddn.mil
Subject:   anonymous ftp
Does anyone know where to ftp security patches for anonymous ftp?
Thanks, Arnold
********************************************************************************
Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de
XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe *  +49 721 608 4331
********************************************************************************
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 16:14:00 EDT
From:      "HQEIS::MCDANIEL" <mcdaniel%hqeis.decnet@hqafsc-vax.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   DDN NETWORK INFORMATION CENTER (NIC)
Andrews AFB

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

                                        Date:     03-Apr-1990 03:22pm EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )


Subject: DDN NETWORK INFORMATION CENTER (NIC)

It seems their is always someone asking about information and if
the Defense Data Network Information Center (DDN NIC) has the 
information and where & how can it be obtained.  To help resolve
future questions, here is a listing describing some of the features
available from the DDN NIC.  Also, the DDN NIC has a 1-800-235-3155
telephone number for requesting information, which I have used
numerous times and always gotten great service and knowledgable
reponses.  Hope this helps cut-down on future request for information
for the DDN NIC.



Rodney A. McDaniel, DAFC
Information Systems Manager
Andrews AFB MD
EMAIL ADDRESS: MCDANIEL@HQAFSC-VAX.AF.MIL
****************************************************************************
[ NETINFO:WHAT-THE-NIC-DOES.TXT ]			   [ 7/88 ]


		 THE DDN NETWORK INFORMATION CENTER (NIC)

The DDN Network Information Center (NIC) is located at SRI
International, Menlo Park, CA, and is funded by the Defense Data
Network (DDN) Defense Communications System (DCS) to provide general
user services to DDN users via telephone, electronic mail, and U.S.
postal mail.

The NIC works closely with the network Host Administrators, Node Site
Coordinators, domain administrators, ARPANET responsible persons,
network protocol groups, vendors, contractors, government agencies,
and military sponsors to assist new users and potential subscribers in
obtaining pertinent network information.

Databases and information servers of interest to network users are
provided, including the WHOIS registry of network users, the NIC/Query
browsing system, TACNEWS, and the official DoD Host Name Service.  The
NIC also serves as the DDN Protocol Repository, and will soon be
providing a BIBLIO server for identifying network documents.  The NIC
is the source for official DDN protocol documents (other than the
MIL-STDs), as well as other DDN documents, and maintains the RFC
(Request for Comments) collection.  Many of the online files are available
through the NIC's automatic mail service, SERVICE@NIC.DDN.MIL.

The NIC registers hosts and domains, assigns IP network numbers and
autonomous system numbers, and provides host name translation tables
and domain name system server files to the DDN/DARPA Internet.  The
NIC also registers network users and issues MILNET TAC access cards.


I.   USER ASSISTANCE SERVICE

Toll-free telephone service is available Monday through Friday, 7 am
to 5 pm, Pacific time.  Users who experience problems with using the
network in general, and with terminal-to-TAC use, in particular, are
encouraged to make use of this service.

     Toll-free:               800-235-3155

     International:           415-859-3695


II.  NIC ONLINE MAILBOXES

To contact the NIC via electronic mail 24 hours a day, 7 days a
week, use these mailboxes:

     NIC@NIC.DDN.MIL             General user assistance, document requests
     REGISTRAR@NIC.DDN.MIL       User registration and WHOIS updates
     HOSTMASTER@NIC.DDN.MIL      Host, domain, network changes and updates
     ACTION@NIC.DDN.MIL          NIC computer operations    
     SUGGESTIONS@NIC.DDN.MIL     Comments on NIC publications and services
     SERVICE@NIC.DDN.MIL         Automatic mail service

III. NIC U.S. POSTAL ADDRESS

Send U.S. postal mail correspondence to:

     DDN Network Information Center
     SRI International, Room EJ291
     333 Ravenswood Avenue
     Menlo Park, CA 94025
 

IV.  NIC COMPUTER SERVICES

The NIC host computer is a DEC-2065, running the TOPS20 operating
system, and its hostname is NIC.DDN.MIL.  It has two network addresses,
and so is accessible from either the MILNET or the ARPANET.  The
network addresses are:

			    26.0.0.73 (MILNET)

NIC online services are available 24 hours a day, 7 days a week.
Operations personnel are in attendance from 6 am - 11 pm weekdays, and
8 am - midnight weekends, Pacific time.  NIC operators are available
at 415-859-5921.


V.   DOCUMENTS DISTRIBUTED BY THE NIC

The NIC publishes and distributes the following documents, all of
which are available in hardcopy and some of which are available
online.  Many of these documents are deposited at the Defense
Technical Information Center (DTIC).  An annotated list of NIC
publications is found in the file NETINFO:NIC-PUBS.TXT on NIC.DDN.MIL.

Title	 			                          Online Filename

 ARPANET Information Brochure . . . . . . . . . . . . . . NETINFO:AIB.DOC
 DDN Defense Data Network Brochure
 DDN New User Guide . . . . . . . . . . . . . . . . . . . NETINFO:NUG.DOC
 DDN Newsletters. . . . . . . . . . . . . . . . .DDN-NEWS:DDN-NEWS-nn.TXT
 DDN Management Bulletins . . . . . . . .DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT
 DDN Protocol Implementations and Vendors Guide . . . . . . . . . . . . .
 . . . . . . . . . . . . . . . . . . . . . . . .NETINFO:VENDORS-GUIDE.DOC
 DDN Protocol Handbook
 DDN Subscriber Interface Guide
 DDN Subscriber Security Guide
 DDN X.25 Host Interface Specification. . . . . . . . . . NETINFO:X25.DOC
 Logical and Geographic Maps of MILNET and ARPANET
 RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . .RFC:RFCnnn.TXT
 RFC Index. . . . . . . . . . . . . . . . . . . . . . . RFC:RFC-INDEX.TXT


 NOTE: In the filenames, the "nn" or the "nnn" should be replaced by the
       number of the newsletter, bulletin or RFC.


VI.  ONLINE INFORMATION SERVERS

     TACNEWS

TACNEWS offers login help for MILNET TAC users, includes the current
list of ARPANET and MILNET TAC dial-up numbers, and provides a
mechanism for reading the DDN Newsletters and Management Bulletins.
Users should read these newsletters and bulletins regularly to stay
current on DDN policies, announcements, and network news items.

     Accessing TACNEWS

From a TAC:   @n <Return>
From TELNET:  connect NIC.DDN.MIL
    
At the NIC.DDN.MIL system prompt "@":  tacnews <Return>


     WHOIS/NICNAME

WHOIS/NICNAME is a NIC program that provides an electronic "white
pages" of network users.  It lists the name, network mailbox, U.S.
postal address, telephone number, and host for all registered users.
Host, TAC, domain, and network information may be obtained from WHOIS
as well.
				
     Accessing WHOIS/NICNAME

From TELNET:  connect NIC.DDN.MIL

At the NIC.DDN.MIL system prompt "@":  whois help <Return> or
                                        nicname help <Return>

WHOIS/NICNAME may also be run from a local host.  WHOIS/NICNAME user
programs for several operating systems are available from the NIC.
Contact the NIC for copies.


     NIC/QUERY

NIC/QUERY contains host information, protocol and other document
information, and access to WHOIS/NICNAME.  NIC/QUERY is geared toward
novice or casual users.

     Accessing NIC/QUERY

From TELNET:  connect NIC.DDN.MIL

At the NIC.DDN.MIL system prompt "@":  nic <Return>


     NAMSER

NAMSER is an internet hostname server on NIC.DDN.MIL port 101 decimal.
This server delivers machine-translatable hostname/address/attribute
information for networks, gateways, and hosts within the DDN.  The
server can deliver a single response or the entire host table,
depending upon the type of query sent.  The server provides the
information outlined in RFC 952 and is itself described in RFC 953.

     Accessing NAMSER

From TELNET:  connect NIC.DDN.MIL 101 <Return>
    	      help <Return>


VII. ONLINE FILES

The NIC maintains a number of online files which are available to
network subscribers via file transfer (FTP).  These files contain
information about protocols, site personnel, hosts and other subjects
relevant to network users.  See the file NETINFO:00NETINFO-INDEX.TXT for
an index to the files in the NETINFO directory.  See also the DDN New
User Guide, or contact the NIC User Assistance service for more
information.

To retrieve any of the NIC's public files, use your local FTP program,
connect to the NIC.DDN.MIL host, and log in as "anonymous" with password
of "guest" (known as the "anonymous login convention").  FTP servers
differ slightly from host to host, so please consult your Host
Administrator for instructions, if needed.

How to Use the NIC's Automated Mail Service

SERVICE@NIC.DDN.MIL is an automated service provided by the DDN
Network Information Center.  It allows access to NIC documents and
information via ordinary electronic mail.  This is especially useful
for people who do not have access to the NIC via a direct Internet
link, such as BITNET, CSNET and UUCP sites.

To use the mail service, send a mail message to SERVICE@NIC.DDN.MIL.
In the SUBJECT field, request the type of service you wish followed by
any needed arguments.  The message body is normally ignored.  The
information you request will be sent back to you as soon as possible.
Large files will be broken into parts and sent to the requestor in
separate messages.

The following services are currently available:

HELP			A help message; a list of current services.
HOST xxx		Returns information about host xxx.  WHOIS xxx can
			also be used to get more details about a host.
IDEA nnn [vvv]		nnn is the IETF idea number or the word INDEX.  For
			a given idea, vvv is the optional version number,
			which defaults to the highest current version.
IEN nnn			nnn is the IEN number or the word INDEX.
NETINFO xxx		xxx is a file name or the word INDEX.
RFC nnn			nnn is the RFC number or the word INDEX.
SEND xxx		xxx is a fully specified file name.
WHOIS xxx		Returns information about xxx from the WHOIS service.
	                Use "WHOIS HELP" for information on how to use WHOIS.

Example SUBJECT lines:

    HELP
    HOST NIC.DDN.MIL
    IDEA 1
    IDEA 4 1
    NETINFO DOMAIN-TEMPLATE.TXT
    RFC 822
    RFC INDEX
    SEND RFC:ASSIGNED-NUMBERS.TXT
    WHOIS LOTTOR, MARK

Send comments or suggestions to SUGGESTIONS@NIC.DDN.MIL.  Send questions
and bug reports to NIC@NIC.DDN.MIL.


VIII. USER REGISTRATION

Host Administrators have overall responsibility for registering their
users.  When new users acquire accounts on MILNET hosts, their Host
Administrator must complete a NIC-generated template to register them
in the NIC database.  Registration is voluntary for ARPANET users.
Names and addresses of Host Administrators are found on the NIC.DDN.MIL
host in the files NETINFO:MIL-HOST-ADMINISTRATORS-A-L.TXT,
NETINFO:MIL-HOST-ADMINISTRATORS-M-Z.TXT and
NETINFO:ARPA-HOST-ADMINISTRATORS.TXT.

End users who require MILNET TAC dial-up access to reach their hosts
must have TAC Access cards that are provided by the NIC.  Approval
for distributing the card is sent to the NIC from the user's Host
Administrator.  Until the user is permanently registered, there are
temporary "Guest" TAC cards available from the Host Administrator for
immediate use.

ARPANET TAC use is authorized by "Responsible Persons" of DARPA
organizations.  A list of DARPA Responsible Persons is in the file
NETINFO:RESPONSIBLE-PERSONS.TXT on the NIC.DDN.MIL host.
[    NETINFO:NIC-PUBS.TXT    ]
                                                            [    10/89    ]

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


                      PUBLICATIONS AVAILABLE FROM THE

                   DDN NETWORK INFORMATION CENTER (NIC)



1.  DDN NEW USER GUIDE

     A "how-to" guide to the DDN for network users, including use of
     network tools, such as electronic mail and file transfer.   Published
     by the NIC, December 1985, Revised November 1987.  Online filename -
     NETINFO:NUG.DOC.

     NIC Price: $10.00 domestic/$13.00 foreign.


2.  DDN PROTOCOL HANDBOOK

     A four-volume reference set of experimental ARPANET and official DoD
     network protocols, together with military standards, implementations
     details and related background information.   Published by the NIC,
     Volumes 1-3 December 1985; Volume 4 August 1989.

     NIC Price: $190.00 per set domestic/$265.00 per set foreign.
     DTIC Order Nos.: Vol. 1 AD-A166 324, Vol. 2 AD-A166 325, Vol. 3
     AD-A166 326 [Vol. 4 DTIC number has not been assigned yet]

     The 1985 DDN Protocol Handbook supersedes:
          Internet Protocol Transition Workbook, March 1982
          Internet Protocol Implementation Guide, August 1982
          Internet Mail Protocols, November 1982
          Internet Telnet Protocol and Options, June 1983
          Miscellaneous Protocols


3. DDN PROTOCOL IMPLEMENTATIONS AND VENDORS GUIDE

     A list of vendor-supplied software and hardware DDN protocol
     implementations, including TCP/IP, X.25, and OSI implementations.
     Published by the NIC, August 1988.  Online filename -
     NETINFO:VENDORS-GUIDE.DOC.

     NIC Price: $45.00 domestic/$55.00 foreign.
     DTIC Order No. AD-A206 354
4.  DDN SUBSCRIBER INTERFACE GUIDE

     Describes alternative hardware connections to the DDN, including
     guidelines for connecting equipment to the DDN.   Published by the
     Defense Communications Agency, July 1983.

     NIC Price: $10.00 domestic/$13.00 foreign.
     DTIC Order No.:  AD-A132 877

5.  DDN SUBSCRIBER SECURITY GUIDE

     A description of the security architecture designed for the DDN.
       Published by the Defense Communications Agency, November 1983.

     NIC Price: $10.00 domestic/$13.00 foreign.
     DTIC Order No.:  AD-A152 524

6.  DDN X.25 HOST INTERFACE SPECIFICATION

     Contains the specific options and features of CCITT Recommendation
     X.25 (1980) and the Federal Information Processing Standard (FIPS)
     100/Federal Standard 1041, (July 1983).   Published by the Defense
     Communications Agency, December 1983.  Online filename -
     NETINFO:X25.DOC.

     NIC Price: $10.00 domestic/$13.00 foreign.
     DTIC Order No.:  AD-A137 427

7. GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)

     The Federal Information Processing Standard (FIPS) describing the
     Federal government's policy, including the DoD transition from TCP/IP
     to ISO international protocols.

     The package contains the Federal Register announcement of the FIPS,
     the GOSIP profile itself, the OSD directive to proceed with the policy
     within DoD, and the GOSIP FIPS draft.
     Online filenames -

     PROTOCOLS:GOSIP-FEDREG.TXT         Federal Register Announcement
     PROTOCOLS:GOSIP-FIPS-DRAFT.TXT     FIPS PUB GOSIP draft
     PROTOCOLS:GOSIP-V1.DOCS            The most recent version
                                        of the GOSIP document
     PROTOCOLS:OSDIR-7-87.TXT           OSD Directive to
                                        adopt OSI protocols

     NIC Price: $10.00 domestic/$13.00 foreign.

8. LOGICAL and GEOGRAPHIC MAPS of MILNET and ARPANET

     Maps of MILNET and ARPANET geographic locations and logical
     connections.   Published by Bolt Beranek and Newman Inc.

     No charge.


9. RFC INDEX, RFCs, RFC SUBSCRIPTION

     Technical notes describing protocol development and related topics of
     interest to the ARPANET and DDN research community.  Online filenames
     are of the form RFC:RFCnnn.TXT (where nnn represents the RFC number)
     and the online index is contained in RFC:RFC-INDEX.TXT.

           NIC Prices:

         RFC index       $5.00 domestic/$8.00 foreign
         RFCs            $5.00 domestic/$8.00 foreign per copy under
                         100 pages
                         $10.00 domestic/$13.00 foreign per copy 100
                         pages and over:
                         (RFCs 806, 809, 841, 905, 909, 1000, 1013,
                         1045, 1117, 1122)
         RFC Subscription
                         $200.00 domestic/$230.00 foreign


                      DDN Network Information Center
                       SRI International, Room EJ291
                           333 Ravenswood Avenue
                           Menlo Park, CA 94025
              800-235-3155 / 415-859-3695 / FAX 415-859-6028

         Defense Technical Information Center (DTIC): 202-274-7633


NOTE: California residents should add a 7% sales tax (with the exception of
military users).

          Domestic includes USA and Canada.



                                                                  Rev 09/89
                             ORDER INFORMATION


DTIC DOCUMENT ORDERS

Military personnel or DoD contractors with proper authorization may obtain
protocol-related documents such as circulars, directives, or memoranda from
the Defense Technical Information Center (DTIC).

DTIC's address and telephone number are:

                       Defense Technical Information Center
                       Cameron Station
                       Alexandria, VA  22304-6145
                       202-274-7633

Contractors and researchers without access to DTIC can obtain these
documents from the NIC.


NIC DOCUMENT ORDERS

Documents can be ordered from the NIC by sending a check, money order or
purchase order for the total amount of the order in US dollars, made
payable to SRI International.  Purchase orders can be sent via facsimile to
415-859-6028, however, a confirming copy must be sent to the address
provided below.  Cash payments or charge cards are not accepted.
California residents should add a 7% sales tax to their order (with the
exception of military users).

Include with all orders your full name, US mailing address with zip code,
telephone number and network mailbox (if available) and send to:

                       DDN Network Information Center
                       SRI International, Room EJ291
                       333 Ravenswood Avenue
                       Menlo Park, CA  94025
                       800-235-3155, 415-859-3695
                       FAX: 415-859-6028




                           SHIPPING INFORMATION

DOMESTIC (USA and Canada):  Our prices include postage.  We ship via UPS
Ground Service.  Please allow 5-10 working days for delivery.

OVERSEAS:  Overseas orders are shipped via "air printed matter".

SPECIAL:  Orders will be shipped via Courier Service by special arrangement
only.  If you want your order to be shipped via a designated Courier
Service, your order must include your Courier Service charge number and
your signature.  NIC order forms are available by request.

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




                                                                  Rev 09/89
[ NETINFO:00NETINFO-INDEX.TXT ]                                [ 3/89, SL ]

                               NETINFO: INDEX

[ NOTES: Where "nn" appears in a file name (e.g. MMM-nn.TXT), it should
         be replaced with a specific number (e.g. MMM-20.TXT).  The number
         of characters in each file is denoted in parenthesis following 
         each file description. ]

     FILE                         DESCRIPTION
 ----------------------------     ------------------------------------------
 00NETINFO-INDEX.TXT..............This file. (7846)

 AIB.DOC..........................ARPANET Info Brochure, online ver. (106638)
 ALTERNATE-DOMAIN-PROCEDURE.TXT...How to register BITNET, CSNET and UUCP
                                  sites in the domain system. (1980)
 ALTERNATE-DOMAIN-TEMPLATE.TXT....Template for registering CSNET and UUCP
                                  sites in the domain system. (4371)
 ARPA-CONFIG.TXT..................Config. of ARPANET hosts (cpu, etc.) (18525)
 ARPA-CONNECT-PROCEDURES.TXT......Admin. steps to attach to ARPANET. (11749)

 ARPA-HOST-ADMINISTRATORS.TXT.....ARPANET Host Administrators. (167587)
 ARPA-MAILBRIDGE-HOMINGS.TXT......ARPANET mailbridge homings. (3432)
 ARPA-NSC.TXT.....................ARPANET Node Site Coordinators. (22266)
 ARPA-PSN-COORD.TXT...............ARPANET NSCs & Host Administrators. (35832)
 ARPA-TAC-USE.TXT.................DARPA guides for use of ARPANET TACs. (3537)

 ARPA-UPGRADE.MAIL................ARPANET PSN 7.0 status reports. (53544)
 ASN.TXT..........................List of assigned autonomous system numbers. 
 ASN-TEMPLATE.TXT.................Template for registering for an autonomous
				  system number. (6816)
 BITNET-DOMAIN-TEMPLATE.TXT.......Template for registering BITNET sites in the
				  domain system. (4646)
 BLACKER.DOC......................Specification of Blacker Interfaces. (33868)

 C30E-INTERFACE-GUIDE.DOC.........C/30 Interface Guide. (213512)
 DELETED-HOSTS.TXT.................ARPA hosts deleted from the Host Table on
                                  10 Oct 88. (19508)
 DOMAIN-CONTACTS.TXT..............Contacts for each domain, by level. (151998)
 DOMAIN-INFO.TXT..................Domains registered with the NIC. (8758)
 DOMAIN-TEMPLATE.TXT..............Questionnaire for domain registration. (6129)

 DOMAINS.TXT......................DDN domain name table. (2926)
 EUR-PAC-PHONES.LIST..............Pointer to FOREIGN-TAC-PHONES.TXT.
 FOREIGN-TAC-PHONES.TXT...........Some European and Pacific MILNET TACs by 
                                  location. (9842)
 GOSIP.DOC........................Pointer to PROTOCOLS:GOSIP-V1.DOC for
                                  GOSIP spec. (266)
 HADMINBYADDR.TXT.................Host Admins. by host net address. (233841)
 HOST-LOCATION.TXT................Host Info sorted geographically. (595301)

 HOSTS.TXT........................Official DDN Internet Host Table. (652121)
 HOSTSERVER-INSTRUCTIONS.TXT......How to use NIC hostname server.  (2727)
 IEN-INDEX.TXT....................Internet Experimental Notes Index. (20352)
 IHOST-TEMPLATE.TXT...............Template for new host table entries. (1986)
 INTEREST-GROUPS.TXT..............DDN Interest/discussion groups. (264525)
 INTEREST-GROUPS-1.TXT............DDN Interest/discussion groups; (11312)
 INTEREST-GROUPS-2.TXT............continuation of -1 file; (46257)
 INTEREST-GROUPS-3.TXT............continuation of -2 file; (49879)
 INTEREST-GROUPS-4.TXT............continuation of -3 file; (47340)
 INTEREST-GROUPS-5.TXT............continuation of -4 file; (49199)
 INTEREST-GROUPS-6.TXT............continuation of -5 file; (39736)
 INTEREST-GROUPS-7.TXT............continuation of -6 file. (20802)
 INTERNET.GATEWAYS................Official DDN Gateway Table. (6303)
 INTERNET.PINGING.................Info needed to use INTERNET.GATEWAYS. (12398)
 INTERNET-NUMBER-TEMPLATE.TXT.....How to request an internet number. (7861)

 KERMIT-INFO.TXT..................Kermit info and how to get it. (2893)
 KERMIT-NICSERVER.TXT.............NIC Kermit server usage info. (2070)
 KERMIT-TAC-INFO.TXT..............How to use Kermit through a TAC. (3179)
 MIL-CONFIG.TXT...................Config of MILNET hosts (cpu, etc.) (115537)
 MIL-HOST-ADMINISTRATORS-A-L.TXT..MILNET Host Administrators (A-L). (499847)

 MIL-HOST-ADMINISTRATORS-M-Z.TXT..MILNET Host Administrators (M-Z). (499878)
 MIL-HOSTS.TXT....................List of only MILNET hosts taken from 
                                  the host table. (265404)
 MIL-MAILBRIDGE-HOMINGS.TXT.......MILNET mailbridge homings. (10306)
 MIL-NSC-TEMPLATE.TXT.............Template for NSCs and their alternates
                                  to use when informing the NIC of 
                                  changes. (6488)
 MIL-NSC.TXT......................MILNET Node Site Coordinators. (79551)
 MIL-PSN-COORD.TXT................MILNET NSCs & Host Administrators. (190970)
 MIL-TACACS-INSTRUCTIONS.TXT......User registration instructions for
                                  Host Administrators. (13843)

 MMM-nn.TXT.......................Text of Multi-Media Mail documents. (1-27)
 MMM-INDEX.TXT....................Multi-Media Mail documents index. (4137)
 NBSOSI-AGREEMENTS.DOC............Pointer to PROTOCOLS:NBSOSI-AGREEMENTS.DOC
                                  for NBS OSI Implementors agreement. (315)
 NETWORKS.TXT.....................Networks portion of HOSTS.TXT.
 NIC-PUBS.TXT.....................Publications available from the NIC. (7547)

 NSC-HADMIN-DUTIES.TXT............Role of NSC and Host Administrator. (8779)
 NUG.DOC..........................DDN New User Guide, online version. (156789)
 OSDIR-1.TXT......................Pointer to PROTOCOLS:OSDIR-1.TXT for Office
                                  of Secretary of Defense Memo. (133)
 OSDIR-2.TXT......................Pointer to PROTOCOLS:OSDIR-2.TXT for Office
                                  of Secretary of Defense Memo. (133)
 OSDIR-3.TXT......................Pointer to PROTOCOLS:OSDIR-3.TXT for Office
                                  of Secretary of Defense Memo. (133)

 OSDIR-4.TXT......................Pointer to PROTOCOLS:OSDIR-4.TXT for Office
                                  of Secretary of Defense Memo for DDN
                                  approval of X.25 protocol. (133)
 OSDIR-5.TXT......................Pointer to PROTOCOLS:OSDIR-5.TXT for Office
                                  of Secretary of Defense Memo. (133)
 PROTOCOLS-DOD.BIB................text version of bibliography of recent
                                  articles on TCP, IP, X.25, TP-4, OSI and
                                  other protocol stds. (16014)
 PROTOCOLS-DOD.PS.................postscript version of bibliography of recent
                                  articles on TCP, IP, X.25, TP-4, OSI and
                                  other protocol stds. (23984)
 RESPONSIBLE-PERSONS.TXT..........Responsible Persons, by organization. (17432)

 RFC-BY-AUTHOR.TXT................RFC Index sorted by Author. (18590)
 RFC-BY-TITLE.TXT.................RFC Index sorted by Title. (46496)
 RFC-INDEX.TXT....................Index to Request-For-Comments. (125843)
 RFC-SETS.TXT.....................List of RFC sets. (9226)
 ROOT-SERVERS.TXT.................List of 5 root servers and their network
				  addresses. (681)

 SENDMAIL-CF-DOC.TXT..............Sendmail config. documentation. (6294)
 SENDMAIL-GENERIC.TXT.............Sendmail for hosts using both Internet and 
                                  UUCP. (12047)
 SENDMAIL-INTERNET-GENERIC.TXT....Sendmail for Internet-only hosts. (10152)
 SIMTEL20.ARCHIVES................Information on public-domain software at 
				  SIMTEL20. (25991)

 TAC-LOCATION.TXT.................List of TACS sorted geographically. (99688)
 TAC-PHONES.LIST..................Pointer to USA-TAC-PHONES.TXT.
 TAC-USER.DOC.....................How to order the TAC Users' Guide. (675)
 TEST.FTP.........................Sample file for FTP practice. (1162)
 TP4-MEMO.TXT.....................DoD memo on transition to OSI TP4. (3173)
 USA-TAC-PHONES.TXT...............Some U.S. MILNET/ARPANET TAC phone numbers
                                  by location. (27967)
 USER-TEMPLATE.TXT................MILNET/ARPANET user registration info. (6355)

 VENDORS-GUIDE.DOC................TCP/IP Vendors Guide, online ver. (549539)
 VENDORS-TEMPLATE.TXT.............Template for TCP/IP implementors. (1689)
 VIRUS-PATCH.TXT..................Fix to virus affecting UNIX and SUN systems.
 WBS-NOTES-INDEX.TXT..............Index to WideBand Satellite Notes. (4760)
 WHAT-THE-NIC-DOES.TXT............Description of Network Info. Ctr. (8112)

 WHO-DDN.TXT......................Names, phones, mailboxes for DDN PMO. (16419)
 WHOIS-INFO.TXT...................Info for system managers & programmers
                                  explaining NIC WHOIS/NICNAME service. (399)
 X25.DOC..........................DDN X.25 Host Interface Spec. (109537)

******************************************************************************

[ NETINFO:MIL-TACACS-INSTRUCTIONS.TXT ]                        [ 2/86, APP ]



               INSTRUCTIONS FOR NETWORK USER REGISTRATION


I.  BRIEF OVERVIEW

   The Defense Data Network Defense Communications Systems (DCS) and the
   Defense Advanced Research Projects Agency (DARPA) have authorized the
   DDN Network Information Center (NIC) to register users on the MILNET and
   the ARPANET and to issue MILNET TAC Access Cards.  The NIC maintains
   the user registration information in the NIC WHOIS Database.  It is the
   intent of the DDN DCS that all network users be registered in the
   WHOIS Database.  This database serves as an online "white pages"
   service, and is also used to produce a hardcopy DDN Directory
   (formerly the ARPANET Directory).  The Host Administrator of each
   host is responsible for registering the users of that host, and for
   authorizing individual account holders to access that host via
   MILNET TACs.  In order to do this, the Host Adminstrator must be
   registered in the WHOIS database and have a network mailbox.  This
   file describes the procedure by which you, as a Host Administrator,
   can register your users and authorize them to access the network
   via MILNET TACs.

II.  GUIDELINES AS TO WHO MAY BE A REGISTERED USER OF THE MILNET/ARPANET

   Users of the DDN network should be engaged in U.S. government business or
   research, or should be actively involved in providing operations or
   system support for government-owned or government-supported
   MILNET/ARPANET computer communications equipment.  Any MILNET or
   ARPANET user with a valid account on a network host may be included
   in the NIC WHOIS Database.

   The intent of the DDN DCS is to let the local hosts manage themselves
   responsibly within the guidelines set down by the government.  In
   accordance, each Host Administrator is responsible for users that he
   or she has authorized to use the network.  The DDN DCS will work with
   the Host Administrators should any problems arise.

III.  USERS REQUESTING ACCESS TO MILNET TACS

   The MILNET TAC Access System (TACACS), which became operational in
   February 1984, controls access to the network by a TAC login
   procedure.  In order to access the network via a MILNET TAC, each
   individual user must have a TAC Access Card issued by the NIC.  In
   order to receive a TAC Access Card, each individual user must by
   registered at the NIC and authorized for TAC access by the Host
   Administrator.

   Users who request MILNET TAC access constitute a special subset of
   registered  users.  The DDN DCS requires that these users be
   individually screened and approved by the authorizing Host
   Administrator.  Also, no one will be given MILNET TAC access without
   first having a valid account on a MILNET/ARPANET host.  The NIC has
   adopted the policy that a MILNET TAC user is "authorized" if the user
   template indicating a need for MILNET TAC access comes to the NIC
   from the authorizing Host Administrator's mailbox.

IV.  REGISTERING USERS

   Use the template in Section X to register individuals with accounts
   on your host.  Complete a template for each individual and separate
   the templates by a blank line.  Fill in all the relevant fields
   following the guidelines provided under Section IX.  It is important
   that you use the NIC template and try to adhere to the same data
   entry style as we have used.  This will allow us to automatically
   input the data into our database, and will minimize the amount of
   editing required.  We will not accept data other than in the template
   form specified.

   You may send blank templates to your users to fill out.  Have them
   return the filled-in templates to you.  Accumulate them into a single
   file.  Review the lists (as you are responsible for the
   authorization of registered users on your host), and send us the
   files as messages to the mailbox,  REGISTRAR@NIC.DDN.MIL.  (See Section
   VIII for further discussion on submitting the templates.)

V.  OBTAINING LISTS OF USERS CURRENTLY IN THE NIC DATABASE

   You may request from the NIC a file of templates of individuals
   currently registered in the NIC WHOIS Database whose primary login
   name is on your host.  The file can be pulled over to your host via
   FTP, updated and returned VIA NETWORK MAIL to
   REGISTRAR@NIC.DDN.MIL.  To delete a user from the database, fill
   in the "Delete" field in the user's template.  DO NOT DELETE the
   template itself.  To add a user to the database, fill out the
   template included under Section X.  Complete a template for each new
   individual.  You can add these to the corrected entries or send them
   as a separate list, whichever you prefer.

VI.  DELETING USERS FROM THE DATABASE

   When a user's account is deleted from your host, the user's record
   should be deleted from the WHOIS Database.  This can be accomplished
   by filling in the "Delete" field in the user's template as described
   in Section V, or by sending a brief network message to
   REGISTRAR@NIC.DDN.MIL giving the user's full name and account name. 
   If a user who has been issued a TAC Access Card is deleted from the
   database, the NIC will automatically invalidate the user's card after
   a number of weeks.  The time delay in invalidating the card is
   intended to provide continued network access for users who are moving
   their accounts to a new host.

VII.  USERS WITH ACCOUNTS ON MORE THAN ONE HOST

   A user should ideally be authorized by the Host Administrator of the
   user's "primary" host, where "primary" is defined as the "home" host
   or the host on which the user has an account to do the primary work
   for which he or she is authorized to use the network.  Some users
   will have several legitimate accounts, in which case the "primary"
   host will probably be the one on which they receive electronic mail,
   or the one which they themselves identify as their "home" host.

   If users do have multiple accounts on more than one MILNET/ARPANET
   host, and if each Host Administrator fills in a template for every
   user on his or her host, the NIC may well receive multiple templates
   for some users.  We are prepared to resolve any resulting
   duplication.
   If a user tells you that a template has already been filled in for
   him or her by another Host Administrator, do not fill in another
   template unless you are sure that your host is the primary host for
   that user.  If you are in doubt or don't know, check with the user.
   The NIC will screen for duplication.

   If the user does not require MILNET TAC access, the template need not
   come from the authorizing Host Administrator's mailbox.  However, as
   stated above, the Host Administrator is responsible for the
   appropriateness of all use of the network by users accessing the network
   from his or her host.  Therefore, it is important that the
   "Authorizing Host" field reflect accurately the host which is the
   "home" host or on which the user is doing his or her primary work.

VIII.  ONLINE MAIL ADDRESS FOR COMPLETED TEMPLATES

   Please send user registration templates in a network message to:

      REGISTRAR@NIC.DDN.MIL

   Remember, if users require MILNET TAC access, the list of templates
   MUST be sent to us from the Host Administrator's mailbox.  As stated,
   this is our guarantee that the users on this list are authorized to
   have MILNET TAC access.

   Please send us all the templates via network mail.

   If the list is too long for your mail system to process, you may
   break the lists arbitrarily (between templates) and send them as a
   set of messages.  If  you do break up the list, please indicate in
   the subject field of each message:  Part 1 of 4, Part 2 of 4, etc.
   To assure that the NIC mail system will be able to process your
   message, do not send a message of over 50,000 characters.

IX.  SPECIFIC INSTRUCTIONS FOR EACH TEMPLATE FIELD

   If all users or a group of users in your list will have identical
   data in any field (i.e., same text of address, phone number,
   authorizing host, etc.),  please enter the full text of the field in
   the first template of the group in the list.  You may then indicate
   that this information is to be repeated by simply entering "*" as the
   text of that field in subsequent templates, (* =  ditto).  The "*"
   may be used only in the following fields:

      U.S. MAIL ADDRESS:
      PHONE:
      AUTHORIZING HOST:
      PRIMARY LOGIN NAME:
      PRIMARY NETWORK MAILBOX:
      TERMINATION DATE:

   FULL NAME:

   The name may be entered in any of the following formats:

      Lastname, Firstname I.
      Lastname, Firstname
      Lastname, I. Middlename
      Lastname, Firstname I., Jr.
      Lastname, Firstname I., III

      where "I." = an initial

      Do not include military rank or professional titles.

   U.S. MAIL ADDRESS - some standard procedures:

      The name of the organization or university should appear on the
      first line.  Do not use acronyms for the name of the organization.
      The second line may contain information such as the department
      name, code, or attention line, followed by a line containing the
      building name or number, room number if you wish to include any of
      these.  The next line should contain the street address or Post
      Office Box.  The last line of the address field should contain the
      city, state and zip code.  If you commonly use a 9 digit zip code,
      enter that.

      DO NOT USE ANY ABBREVIATIONS OR ACRONYMS, with the exception of

         Incorporated.......Inc.
         Limited............Ltd.
         Corporation........Corp.
         Company............Co.
         Post Office Box....P.O. Box

      Separate lines of the address by a carriage return.

   PHONE:  

      Up to four phone numbers are allowed.  Acceptable formats are:

      U.S. numbers

      (123) 456-7890
      (123) 456-7890 ext 123
      (123) 456-7890 (AV) 567-7890
      (123) 456-7890 (AV) 567-7890 (FTS) 667-7890
      (123) 456-7890 or 456-0987
      (123) 456-7890 or 456-0987 (AV) 567-7890 or 567-0987

      Overseas numbers

      [49] 711-123456 or (AV) 420-1234 or (M) 8765-1234 (For overseas
      numbers, give number through country code with country code in
      brackets.)

   AUTHORIZING HOST:

      This is the name of the host which the user considers his or her
      "home" host, or on which the user is doing the primary work for
      which he or she is authorized to use the MILNET or ARPANET.

      Enter the OFFICIAL HOSTNAME rather than an approved nickname.

   PRIMARY LOGIN NAME:

      This is the primary login name/username/directory name of the
      user on the authorizing host.

      If the login name is a part of the security system on your host
      and therefore should be kept secret, do not enter it in this
      field.

      The primary login name may be a group directory name if it is the
      only one the individual uses.

   PRIMARY NETWORK MAILBOX:

      This is the mailbox where this individual prefers to receive
      mail.  This may or may not be his or her primary login name on
      your host.  If mail addresses are case dependent on your host,
      specify the mailbox string accordingly.  Otherwise enter the
      string in upper case.

      Separate the username and hostname parts of the mailbox by "@".

      Format:  USERNAME@HOSTNAME, e.g. SMITH@SRI-NIC

      For those hosts whose official hostname is a Fully Qualified
      Domain Name (FQDN), enter the FQDN in the hostname part of the
      mailbox.  The FQDN is preferred, as in:  SMITH@AI.AI.MIT.EDU

   MILNET TAC ACCESS? (y/n):

      For a user to be authorized for MILNET TAC access, this field must
      be filled in with "y" or "yes".  This is the means by which you, as
      Host Administrator, indicate to us that this user is authorized
      for MILNET TAC access and will require a MILNET TAC Access Card.
      A TAC Access Card will be automatically generated for each
      individual whose template contains "y" or "yes" in this field,
      providing that the template is sent to us from the Host
      Administrator's mailbox.

   TERMINATION DATE:

      The DEROS date (Date Eligible for Return from Overseas) for military
      users, estimated date of graduation for students, estimated
      elapse date for temporary users is requested here for use on
      military hosts.  Others may use the field if they wish.  It is
      not currently used in maintenance of the WHOIS database and will
      not cause automatic deletion of records from the database.

      Format:  MO/YR, e.g., 10/83, 02/84

   HANDLE:

      The handle is the unique identifying label for the record.

      This field appears in templates of currently registered users.

         DO NOT ALTER THIS FIELD.

      This field does not appear in the blank template.  Do not specify
      a handle for the ADDITIONS.  Our program will automatically
      generate a unique identifier (handle) for each individual
      template.

   DELETE? (y/n):

      If the individual no longer has a login account on your host, mark
      this field with a "y" or "yes".  DO NOT DELETE THE WHOLE TEMPLATE.

X.  SAMPLE BLANK TEMPLATE

   FULL NAME:
   U.S. MAIL ADDRESS:
   PHONE:
   AUTHORIZING HOST:
   PRIMARY LOGIN NAME:
   PRIMARY NETWORK MAILBOX:
   MILNET TAC ACCESS? (y/n):
   TERMINATION DATE:


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

[ NETINFO:USER-TEMPLATE.TXT ]                              [ 6/88, SS ]

                 PROCEDURE FOR MILNET/ARPANET REGISTRATION

This file contains information for registering individual users in the
official MILNET/ARPANET User Registration (WHOIS) Database which is
maintained by the DDN Network Information Center (DDN NIC) on SRI-NIC.  A
user registration template has been created to standardize the registration
procedure and guarantee that the DDN NIC will receive complete information
about each user.  This file contains instructions for filling in the User
Registration template, instructions for sending the template to the DDN
NIC, a sample template, and a blank template.

I.  GUIDELINES AS TO WHO MAY BE A REGISTERED USER OF THE MILNET/ARPANET

Any MILNET or ARPANET user with a valid account on a network host may be
included in the NIC WHOIS Database.  Users of the network should be engaged
in U.S. government business or research, or should be actively involved in
providing operations or system support for government-owned or
government-supported MILNET/ARPANET computer communications equipment.


II.  HOW TO FILL IN THE USER REGISTRATION TEMPLATE

Using an editor of your choice, create a file containing the blank
template and fill in all relevant fields.  Each field should begin on a new
line.  Detailed instructions for filling out the template are given below
under SPECIFIC INSTRUCTIONS FOR EACH FIELD.

214
III.  USERS REQUESTING ACCESS TO MILNET TACS

If you require TAC access, please contact your Host Administrator.

You can determine the name and network mailbox of your Host 
Administrator by consulting the files

      NETINFO:MIL-HOST-ADMINISTRATORS-A-L.TXT
      NETINFO:MIL-HOST-ADMINISTRATORS-M-Z.TXT
      NETINFO:ARPA-HOST-ADMINISTRATORS.TXT

on the SRI-NIC machine.  These files can be FTPed to your host.

Alternatively, you may access the WHOIS/NICNAME Server to receive host
information online, including the name and network mailbox of your Host
Administrator, by executing the command:

      WHOIS HOSTNAME<Return> (where "hostname" is the name of your host)


IV.  WHERE TO SEND THE COMPLETED TEMPLATE

The completed template should be sent to REGISTRAR@NIC.DDN.MIL.
V.  SPECIFIC INSTRUCTIONS FOR EACH TEMPLATE FIELD

   FULL NAME: 

The name may be entered in any of the following formats:

      Lastname, Firstname I.
      Lastname, Firstname
      Lastname, I. Middlename
      Lastname, Firstname I., Jr.
      Lastname, Firstname I., III

      where "I." = an initial

      Do not include military rank or professional titles.

   U.S. MAIL ADDRESS - some standard procedures:

   Line 1: The name of your organization; do not use acronyms.
   Line 2: Information such as the department name, code, or attention line.
   Line 3: (optional) The building name or number, room number).
   Line 4: Your street address or Post Office Box.
   Line 5: City, state and zip code.  If you commonly use a 9 digit zip
           code, enter that.

      DO NOT USE ANY ABBREVIATIONS OR ACRONYMS, with the exception of

         Incorporated.......Inc.
         Limited............Ltd.
         Corporation........Corp.
         Company............Co.
         Post Office Box....P.O. Box

      Separate lines of the address by a carriage return.

   PHONE:

      Up to four phone numbers are allowed.  Acceptable formats are:

      U.S. numbers

      (123) 456-7890
      (123) 456-7890 ext 123
      (123) 456-7890 (DSN) 567-7890
      (123) 456-7890 (DSN) 567-7890 (FTS) 667-7890
      (123) 456-7890 or 456-0987 (DSN) 567-7890 or 567-0987

      Overseas numbers

      [49] 711-123456 or (DSN) 420-1234 or (M) 8765-1234
      (For overseas numbers, specify the country code in brackets.)

   AUTHORIZING HOST:

      This is the name of the user's "home" host, or on which the user
      is doing the primary work for which he or she is authorized to
      use the MILNET or ARPANET.

      Enter the OFFICIAL HOSTNAME rather than an approved nickname.

   PRIMARY LOGIN NAME:

      This is the primary login name/username/directory name of the
      user on the authorizing host.

      If the login name is a part of the security system on your host 
      and therefore should be kept secret, do not enter it in this 
      field.

      The primary login name may be a group directory name if it is the
      only one the individual uses.

   PRIMARY NETWORK MAILBOX:

      This is the mailbox where this individual prefers to receive
      mail.  This may or may not be his or her primary login name on
      the host.  If mail addresses are case dependent on your host,
      specify the mailbox string accordingly.  Otherwise enter the
      string in upper case.

      Separate the username and hostname parts of the mailbox by "@".

      Format:  USERNAME@HOSTNAME
      Example: SMITH@NIC.DDN.MIL

      For those hosts whose official hostname is a Fully Qualified 
      Domain Name (FQDN), enter the FQDN in the hostname part of the 
      mailbox.  The FQDN is preferred.

      Example: Smith@AI.AI.MIT.EDU

   TERMINATION DATE:

      The DEROS date (Date Eligible for Return from Overseas) for military 
      users, estimated date of graduation for students, estimated 
      elapse date for temporary users.

      This field was requested for use on military hosts.  Others may 
      use the field if they wish.

      Format:  MO/YR 
      Example: 10/87 

=======================================================================
SAMPLE USER REGISTRATION TEMPLATE
=======================================================================

FULL NAME: Kahn, Susan
U.S. MAIL ADDRESS: SRI International
Telecommunication Sciences Center
Network Information Center
333 Ravenswood Avenue
Menlo Park, California 94025
PHONE: (415) 859-6111
AUTHORIZING HOST: SRI-NIC
PRIMARY LOGIN NAME: SKAHN
PRIMARY NETWORK MAILBOX: SKAHN@NIC.DDN.MIL
TERMINATION DATE:

=======================================================================
USER REGISTRATION TEMPLATE
=======================================================================

FULL NAME:
U.S. MAIL ADDRESS:
PHONE:
AUTHORIZING HOST:
PRIMARY LOGIN NAME:
PRIMARY NETWORK MAILBOX:
TERMINATION DATE:

-------



-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 03 Apr 90 09:19:54 +0200
From:      "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@CUNYVM.CUNY.EDU>
To:        TCP-IP ARPA Discussions <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: POP2 Server
On Fri, 30 Mar 90 13:41:46 CST <MAINT@ASNTSU.ASN.NET> said:
>question is where does the server get the mail from that is to be delivered
>when a client connects?
In a pure DDN setup, the only place it can come from is the SMTP server.
On a mixed (gateway) setup, from any place mail can come from.....
>How does the server know which client the mail is
>for and what folder, between the time it receives the mail until the client
>connects to retreive the mail? Is there a hook in the SMTP server that
>knows when mail has to be forwarded to the POP2 server rather than a
>resident user? Since the client must have an account on the host running
>the server does SMTP store the mail for that user per normal and then the
>POP2 server access it there? Is there a standard that shows where and how
>the POP2 server determines what mail is waiting?
It depends on how the design is made. One can imagine a server that 'steals'
information from regular mailboxes. This means that accounts must be created
for all users of the POP service. It also means that such a server can only
serve people whose Internet address is 'account@domain.address.of.POP.host',
which I feel too limited in these days of 'logical addresses', where the
local-part is *not* an account and domain is *not* naming iron. The
advantages of such a design are that the SMTP server has nothing to do, and
that a client can read his mail either by using POP, or by a regular login
on the server. Note : in this case, the POP name will probably be the
account, and the POP password the account password.

Another possibility, which I feel would be much more useful when a large
community is to be served, would be to have a POP server keeping it's own
storage area and its own list of clients. Such a server would by itself be
a true MS (mail store). For each client, there would be a translation entry
local-part@domain -> POP name and password. Of course, the SMTP server
would also need local information (local = not coming from the DNS) about
which incoming addresses should trigger forwarding to the POP server. The
exact path for mail file transfer between SMTP server and POP server is a
purely local matter (it's on the same physical machine). The fact that a
SMTP server needs local information for final delivery into its neigboorhood
is not against the spirit of the DNS (there has been a message from Graig
Partridge saying just that in the last days...).

Disclaimer : I am not an expert in anything. I just happen to be looking
for a way to serve a large mail user community, and these ramblings simply
reflect my current state of though on the matter.             /AF
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 17:16:14 GMT
From:      zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   Re:  Diskless Sun Booter

>Hi, I am faced with the following problem:  I can get a diskless Sun
>3/50 for $2000, but I need disks for it.  A shoebox with a 150MB disk
>costs $2500 (used!!!).

May be it would be best to buy a disk for your sun elsewhere.
There are disk subsystems with case and with power supply
fitting to Suns, but much cheaper as shoeboxes.

I know some dealers for that in West Germany and I assume it will
be easy to find the same in other countries by reading ad's
in Computer Magazines.


Joerg

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 19:49:24 GMT
From:      usc!cs.utexas.edu!asuvax!mcdphx!varese.UUCP!kjj@ucsd.edu  (Kevin Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 4.2BSD lpr spec exists.
In article <9003291950.AA07210@sun.soe.clarkson.edu.soe> nelson@SUN.SOE.CLARKSON.EDU (Russ Nelson) writes:
>Five years ago, Shawn Routhier write a document that describes the lpr
>protcol.  I found that document in husc6.harvard.edu:/pub/pcip/doc.tar.Z:/doc/lprspec.txt.
>I'll put it sun.soe.clarkson.edu:/pub/ka9q/lprspec.txt.

How big is that doc?  Could it be posted on 'the net'?

#include <standard_disclaimer>
.-----------------------------------------------------------------------------.
| Kevin Johnson                                      asuvax!mcdphx!QIS1!kjj   |
| QIS System Administrator  Motorola MCD             kjj@phx.mcd.mot.com      |
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 20:14:00 GMT
From:      mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL")
To:        comp.protocols.tcp-ip
Subject:   DDN NETWORK INFORMATION CENTER (NIC)

Andrews AFB

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

                                        Date:     03-Apr-1990 03:22pm EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )


Subject: DDN NETWORK INFORMATION CENTER (NIC)

It seems their is always someone asking about information and if
the Defense Data Network Information Center (DDN NIC) has the 
information and where & how can it be obtained.  To help resolve
future questions, here is a listing describing some of the features
available from the DDN NIC.  Also, the DDN NIC has a 1-800-235-3155
telephone number for requesting information, which I have used
numerous times and always gotten great service and knowledgable
reponses.  Hope this helps cut-down on future request for information
for the DDN NIC.



Rodney A. McDaniel, DAFC
Information Systems Manager
Andrews AFB MD
EMAIL ADDRESS: MCDANIEL@HQAFSC-VAX.AF.MIL
 ****************************************************************************
[ NETINFO:WHAT-THE-NIC-DOES.TXT ]			   [ 7/88 ]


		 THE DDN NETWORK INFORMATION CENTER (NIC)

The DDN Network Information Center (NIC) is located at SRI
International, Menlo Park, CA, and is funded by the Defense Data
Network (DDN) Defense Communications System (DCS) to provide general
user services to DDN users via telephone, electronic mail, and U.S.
postal mail.

The NIC works closely with the network Host Administrators, Node Site
Coordinators, domain administrators, ARPANET responsible persons,
network protocol groups, vendors, contractors, government agencies,
and military sponsors to assist new users and potential subscribers in
obtaining pertinent network information.

Databases and information servers of interest to network users are
provided, including the WHOIS registry of network users, the NIC/Query
browsing system, TACNEWS, and the official DoD Host Name Service.  The
NIC also serves as the DDN Protocol Repository, and will soon be
providing a BIBLIO server for identifying network documents.  The NIC
is the source for official DDN protocol documents (other than the
MIL-STDs), as well as other DDN documents, and maintains the RFC
(Request for Comments) collection.  Many of the online files are available
through the NIC's automatic mail service, SERVICE@NIC.DDN.MIL.

The NIC registers hosts and domains, assigns IP network numbers and
autonomous system numbers, and provides host name translation tables
and domain name system server files to the DDN/DARPA Internet.  The
NIC also registers network users and issues MILNET TAC access cards.


I.   USER ASSISTANCE SERVICE

Toll-free telephone service is available Monday through Friday, 7 am
to 5 pm, Pacific time.  Users who experience problems with using the
network in general, and with terminal-to-TAC use, in particular, are
encouraged to make use of this service.

     Toll-free:               800-235-3155

     International:           415-859-3695


II.  NIC ONLINE MAILBOXES

To contact the NIC via electronic mail 24 hours a day, 7 days a
week, use these mailboxes:

     NIC@NIC.DDN.MIL             General user assistance, document requests
     REGISTRAR@NIC.DDN.MIL       User registration and WHOIS updates
     HOSTMASTER@NIC.DDN.MIL      Host, domain, network changes and updates
     ACTION@NIC.DDN.MIL          NIC computer operations    
     SUGGESTIONS@NIC.DDN.MIL     Comments on NIC publications and services
     SERVICE@NIC.DDN.MIL         Automatic mail service
 
III. NIC U.S. POSTAL ADDRESS

Send U.S. postal mail correspondence to:

     DDN Network Information Center
     SRI International, Room EJ291
     333 Ravenswood Avenue
     Menlo Park, CA 94025
 

IV.  NIC COMPUTER SERVICES

The NIC host computer is a DEC-2065, running the TOPS20 operating
system, and its hostname is NIC.DDN.MIL.  It has two network addresses,
and so is accessible from either the MILNET or the ARPANET.  The
network addresses are:

			    26.0.0.73 (MILNET)

NIC online services are available 24 hours a day, 7 days a week.
Operations personnel are in attendance from 6 am - 11 pm weekdays, and
8 am - midnight weekends, Pacific time.  NIC operators are available
at 415-859-5921.


V.   DOCUMENTS DISTRIBUTED BY THE NIC

The NIC publishes and distributes the following documents, all of
which are available in hardcopy and some of which are available
online.  Many of these documents are deposited at the Defense
Technical Information Center (DTIC).  An annotated list of NIC
publications is found in the file NETINFO:NIC-PUBS.TXT on NIC.DDN.MIL.

Title	 			                          Online Filename

 ARPANET Information Brochure . . . . . . . . . . . . . . NETINFO:AIB.DOC
 DDN Defense Data Network Brochure
 DDN New User Guide . . . . . . . . . . . . . . . . . . . NETINFO:NUG.DOC
 DDN Newsletters. . . . . . . . . . . . . . . . .DDN-NEWS:DDN-NEWS-nn.TXT
 DDN Management Bulletins . . . . . . . .DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT
 DDN Protocol Implementations and Vendors Guide . . . . . . . . . . . . .
 . . . . . . . . . . . . . . . . . . . . . . . .NETINFO:VENDORS-GUIDE.DOC
 DDN Protocol Handbook
 DDN Subscriber Interface Guide
 DDN Subscriber Security Guide
 DDN X.25 Host Interface Specification. . . . . . . . . . NETINFO:X25.DOC
 Logical and Geographic Maps of MILNET and ARPANET
 RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . .RFC:RFCnnn.TXT
 RFC Index. . . . . . . . . . . . . . . . . . . . . . . RFC:RFC-INDEX.TXT


 NOTE: In the filenames, the "nn" or the "nnn" should be replaced by the
       number of the newsletter, bulletin or RFC.
 

VI.  ONLINE INFORMATION SERVERS

     TACNEWS

TACNEWS offers login help for MILNET TAC users, includes the current
list of ARPANET and MILNET TAC dial-up numbers, and provides a
mechanism for reading the DDN Newsletters and Management Bulletins.
Users should read these newsletters and bulletins regularly to stay
current on DDN policies, announcements, and network news items.

     Accessing TACNEWS

From a TAC:   @n <Return>
From TELNET:  connect NIC.DDN.MIL
    
At the NIC.DDN.MIL system prompt "@":  tacnews <Return>


     WHOIS/NICNAME

WHOIS/NICNAME is a NIC program that provides an electronic "white
pages" of network users.  It lists the name, network mailbox, U.S.
postal address, telephone number, and host for all registered users.
Host, TAC, domain, and network information may be obtained from WHOIS
as well.
				
     Accessing WHOIS/NICNAME

From TELNET:  connect NIC.DDN.MIL

At the NIC.DDN.MIL system prompt "@":  whois help <Return> or
                                        nicname help <Return>

WHOIS/NICNAME may also be run from a local host.  WHOIS/NICNAME user
programs for several operating systems are available from the NIC.
Contact the NIC for copies.


     NIC/QUERY

NIC/QUERY contains host information, protocol and other document
information, and access to WHOIS/NICNAME.  NIC/QUERY is geared toward
novice or casual users.

     Accessing NIC/QUERY

From TELNET:  connect NIC.DDN.MIL

At the NIC.DDN.MIL system prompt "@":  nic <Return>


     NAMSER

NAMSER is an internet hostname server on NIC.DDN.MIL port 101 decimal.
This server delivers machine-translatable hostname/address/attribute
information for networks, gateways, and hosts within the DDN.  The
server can deliver a single response or the entire host table,
depending upon the type of query sent.  The server provides the
information outlined in RFC 952 and is itself described in RFC 953.
 
     Accessing NAMSER

From TELNET:  connect NIC.DDN.MIL 101 <Return>
    	      help <Return>


VII. ONLINE FILES

The NIC maintains a number of online files which are available to
network subscribers via file transfer (FTP).  These files contain
information about protocols, site personnel, hosts and other subjects
relevant to network users.  See the file NETINFO:00NETINFO-INDEX.TXT for
an index to the files in the NETINFO directory.  See also the DDN New
User Guide, or contact the NIC User Assistance service for more
information.

To retrieve any of the NIC's public files, use your local FTP program,
connect to the NIC.DDN.MIL host, and log in as "anonymous" with password
of "guest" (known as the "anonymous login convention").  FTP servers
differ slightly from host to host, so please consult your Host
Administrator for instructions, if needed.

How to Use the NIC's Automated Mail Service

SERVICE@NIC.DDN.MIL is an automated service provided by the DDN
Network Information Center.  It allows access to NIC documents and
information via ordinary electronic mail.  This is especially useful
for people who do not have access to the NIC via a direct Internet
link, such as BITNET, CSNET and UUCP sites.

To use the mail service, send a mail message to SERVICE@NIC.DDN.MIL.
In the SUBJECT field, request the type of service you wish followed by
any needed arguments.  The message body is normally ignored.  The
information you request will be sent back to you as soon as possible.
Large files will be broken into parts and sent to the requestor in
separate messages.

The following services are currently available:

HELP			A help message; a list of current services.
HOST xxx		Returns information about host xxx.  WHOIS xxx can
			also be used to get more details about a host.
IDEA nnn [vvv]		nnn is the IETF idea number or the word INDEX.  For
			a given idea, vvv is the optional version number,
			which defaults to the highest current version.
IEN nnn			nnn is the IEN number or the word INDEX.
NETINFO xxx		xxx is a file name or the word INDEX.
RFC nnn			nnn is the RFC number or the word INDEX.
SEND xxx		xxx is a fully specified file name.
WHOIS xxx		Returns information about xxx from the WHOIS service.
	                Use "WHOIS HELP" for information on how to use WHOIS.

Example SUBJECT lines:

    HELP
    HOST NIC.DDN.MIL
    IDEA 1
    IDEA 4 1
    NETINFO DOMAIN-TEMPLATE.TXT
    RFC 822
    RFC INDEX
    SEND RFC:ASSIGNED-NUMBERS.TXT
    WHOIS LOTTOR, MARK
 
Send comments or suggestions to SUGGESTIONS@NIC.DDN.MIL.  Send questions
and bug reports to NIC@NIC.DDN.MIL.


VIII. USER REGISTRATION

Host Administrators have overall responsibility for registering their
users.  When new users acquire accounts on MILNET hosts, their Host
Administrator must complete a NIC-generated template to register them
in the NIC database.  Registration is voluntary for ARPANET users.
Names and addresses of Host Administrators are found on the NIC.DDN.MIL
host in the files NETINFO:MIL-HOST-ADMINISTRATORS-A-L.TXT,
NETINFO:MIL-HOST-ADMINISTRATORS-M-Z.TXT and
NETINFO:ARPA-HOST-ADMINISTRATORS.TXT.

End users who require MILNET TAC dial-up access to reach their hosts
must have TAC Access cards that are provided by the NIC.  Approval
for distributing the card is sent to the NIC from the user's Host
Administrator.  Until the user is permanently registered, there are
temporary "Guest" TAC cards available from the Host Administrator for
immediate use.

ARPANET TAC use is authorized by "Responsible Persons" of DARPA
organizations.  A list of DARPA Responsible Persons is in the file
NETINFO:RESPONSIBLE-PERSONS.TXT on the NIC.DDN.MIL host.
[    NETINFO:NIC-PUBS.TXT    ]
                                                            [    10/89    ]

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


                      PUBLICATIONS AVAILABLE FROM THE

                   DDN NETWORK INFORMATION CENTER (NIC)



1.  DDN NEW USER GUIDE

     A "how-to" guide to the DDN for network users, including use of
     network tools, such as electronic mail and file transfer.   Published
     by the NIC, December 1985, Revised November 1987.  Online filename -
     NETINFO:NUG.DOC.

     NIC Price: $10.00 domestic/$13.00 foreign.


2.  DDN PROTOCOL HANDBOOK

     A four-volume reference set of experimental ARPANET and official DoD
     network protocols, together with military standards, implementations
     details and related background information.   Published by the NIC,
     Volumes 1-3 December 1985; Volume 4 August 1989.

     NIC Price: $190.00 per set domestic/$265.00 per set foreign.
     DTIC Order Nos.: Vol. 1 AD-A166 324, Vol. 2 AD-A166 325, Vol. 3
     AD-A166 326 [Vol. 4 DTIC number has not been assigned yet]

     The 1985 DDN Protocol Handbook supersedes:
          Internet Protocol Transition Workbook, March 1982
          Internet Protocol Implementation Guide, August 1982
          Internet Mail Protocols, November 1982
          Internet Telnet Protocol and Options, June 1983
          Miscellaneous Protocols


3. DDN PROTOCOL IMPLEMENTATIONS AND VENDORS GUIDE

     A list of vendor-supplied software and hardware DDN protocol
     implementations, including TCP/IP, X.25, and OSI implementations.
     Published by the NIC, August 1988.  Online filename -
     NETINFO:VENDORS-GUIDE.DOC.

     NIC Price: $45.00 domestic/$55.00 foreign.
     DTIC Order No. AD-A206 354
4.  DDN SUBSCRIBER INTERFACE GUIDE

     Describes alternative hardware connections to the DDN, including
     guidelines for connecting equipment to the DDN.   Published by the
     Defense Communications Agency, July 1983.

     NIC Price: $10.00 domestic/$13.00 foreign.
     DTIC Order No.:  AD-A132 877

5.  DDN SUBSCRIBER SECURITY GUIDE

     A description of the security architecture designed for the DDN.
       Published by the Defense Communications Agency, November 1983.

     NIC Price: $10.00 domestic/$13.00 foreign.
     DTIC Order No.:  AD-A152 524
 
6.  DDN X.25 HOST INTERFACE SPECIFICATION

     Contains the specific options and features of CCITT Recommendation
     X.25 (1980) and the Federal Information Processing Standard (FIPS)
     100/Federal Standard 1041, (July 1983).   Published by the Defense
     Communications Agency, December 1983.  Online filename -
     NETINFO:X25.DOC.

     NIC Price: $10.00 domestic/$13.00 foreign.
     DTIC Order No.:  AD-A137 427

7. GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)

     The Federal Information Processing Standard (FIPS) describing the
     Federal government's policy, including the DoD transition from TCP/IP
     to ISO international protocols.

     The package contains the Federal Register announcement of the FIPS,
     the GOSIP profile itself, the OSD directive to proceed with the policy
     within DoD, and the GOSIP FIPS draft.
     Online filenames -

     PROTOCOLS:GOSIP-FEDREG.TXT         Federal Register Announcement
     PROTOCOLS:GOSIP-FIPS-DRAFT.TXT     FIPS PUB GOSIP draft
     PROTOCOLS:GOSIP-V1.DOCS            The most recent version
                                        of the GOSIP document
     PROTOCOLS:OSDIR-7-87.TXT           OSD Directive to
                                        adopt OSI protocols

     NIC Price: $10.00 domestic/$13.00 foreign.

8. LOGICAL and GEOGRAPHIC MAPS of MILNET and ARPANET

     Maps of MILNET and ARPANET geographic locations and logical
     connections.   Published by Bolt Beranek and Newman Inc.

     No charge.


9. RFC INDEX, RFCs, RFC SUBSCRIPTION

     Technical notes describing protocol development and related topics of
     interest to the ARPANET and DDN research community.  Online filenames
     are of the form RFC:RFCnnn.TXT (where nnn represents the RFC number)
     and the online index is contained in RFC:RFC-INDEX.TXT.

           NIC Prices:

         RFC index       $5.00 domestic/$8.00 foreign
         RFCs            $5.00 domestic/$8.00 foreign per copy under
                         100 pages
                         $10.00 domestic/$13.00 foreign per copy 100
                         pages and over:
                         (RFCs 806, 809, 841, 905, 909, 1000, 1013,
                         1045, 1117, 1122)
         RFC Subscription
                         $200.00 domestic/$230.00 foreign
 

                      DDN Network Information Center
                       SRI International, Room EJ291
                           333 Ravenswood Avenue
                           Menlo Park, CA 94025
              800-235-3155 / 415-859-3695 / FAX 415-859-6028

         Defense Technical Information Center (DTIC): 202-274-7633


NOTE: California residents should add a 7% sales tax (with the exception of
military users).

          Domestic includes USA and Canada.



                                                                  Rev 09/89
                             ORDER INFORMATION


DTIC DOCUMENT ORDERS

Military personnel or DoD contractors with proper authorization may obtain
protocol-related documents such as circulars, directives, or memoranda from
the Defense Technical Information Center (DTIC).

DTIC's address and telephone number are:

                       Defense Technical Information Center
                       Cameron Station
                       Alexandria, VA  22304-6145
                       202-274-7633

Contractors and researchers without access to DTIC can obtain these
documents from the NIC.


NIC DOCUMENT ORDERS

Documents can be ordered from the NIC by sending a check, money order or
purchase order for the total amount of the order in US dollars, made
payable to SRI International.  Purchase orders can be sent via facsimile to
415-859-6028, however, a confirming copy must be sent to the address
provided below.  Cash payments or charge cards are not accepted.
California residents should add a 7% sales tax to their order (with the
exception of military users).

Include with all orders your full name, US mailing address with zip code,
telephone number and network mailbox (if available) and send to:

                       DDN Network Information Center
                       SRI International, Room EJ291
                       333 Ravenswood Avenue
                       Menlo Park, CA  94025
                       800-235-3155, 415-859-3695
                       FAX: 415-859-6028

 


                           SHIPPING INFORMATION

DOMESTIC (USA and Canada):  Our prices include postage.  We ship via UPS
Ground Service.  Please allow 5-10 working days for delivery.

OVERSEAS:  Overseas orders are shipped via "air printed matter".

SPECIAL:  Orders will be shipped via Courier Service by special arrangement
only.  If you want your order to be shipped via a designated Courier
Service, your order must include your Courier Service charge number and
your signature.  NIC order forms are available by request.

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




                                                                  Rev 09/89
[ NETINFO:00NETINFO-INDEX.TXT ]                                [ 3/89, SL ]

                               NETINFO: INDEX

[ NOTES: Where "nn" appears in a file name (e.g. MMM-nn.TXT), it should
         be replaced with a specific number (e.g. MMM-20.TXT).  The number
         of characters in each file is denoted in parenthesis following 
         each file description. ]

     FILE                         DESCRIPTION
 ----------------------------     ------------------------------------------
 00NETINFO-INDEX.TXT..............This file. (7846)

 AIB.DOC..........................ARPANET Info Brochure, online ver. (106638)
 ALTERNATE-DOMAIN-PROCEDURE.TXT...How to register BITNET, CSNET and UUCP
                                  sites in the domain system. (1980)
 ALTERNATE-DOMAIN-TEMPLATE.TXT....Template for registering CSNET and UUCP
                                  sites in the domain system. (4371)
 ARPA-CONFIG.TXT..................Config. of ARPANET hosts (cpu, etc.) (18525)
 ARPA-CONNECT-PROCEDURES.TXT......Admin. steps to attach to ARPANET. (11749)

 ARPA-HOST-ADMINISTRATORS.TXT.....ARPANET Host Administrators. (167587)
 ARPA-MAILBRIDGE-HOMINGS.TXT......ARPANET mailbridge homings. (3432)
 ARPA-NSC.TXT.....................ARPANET Node Site Coordinators. (22266)
 ARPA-PSN-COORD.TXT...............ARPANET NSCs & Host Administrators. (35832)
 ARPA-TAC-USE.TXT.................DARPA guides for use of ARPANET TACs. (3537)

 ARPA-UPGRADE.MAIL................ARPANET PSN 7.0 status reports. (53544)
 ASN.TXT..........................List of assigned autonomous system numbers. 
 ASN-TEMPLATE.TXT.................Template for registering for an autonomous
				  system number. (6816)
 BITNET-DOMAIN-TEMPLATE.TXT.......Template for registering BITNET sites in the
				  domain system. (4646)
 BLACKER.DOC......................Specification of Blacker Interfaces. (33868)

 C30E-INTERFACE-GUIDE.DOC.........C/30 Interface Guide. (213512)
 DELETED-HOSTS.TXT.................ARPA hosts deleted from the Host Table on
                                  10 Oct 88. (19508)
 DOMAIN-CONTACTS.TXT..............Contacts for each domain, by level. (151998)
 DOMAIN-INFO.TXT..................Domains registered with the NIC. (8758)
 DOMAIN-TEMPLATE.TXT..............Questionnaire for domain registration. (6129)

 DOMAINS.TXT......................DDN domain name table. (2926)
 EUR-PAC-PHONES.LIST..............Pointer to FOREIGN-TAC-PHONES.TXT.
 FOREIGN-TAC-PHONES.TXT...........Some European and Pacific MILNET TACs by 
                                  location. (9842)
 GOSIP.DOC........................Pointer to PROTOCOLS:GOSIP-V1.DOC for
                                  GOSIP spec. (266)
 HADMINBYADDR.TXT.................Host Admins. by host net address. (233841)
 HOST-LOCATION.TXT................Host Info sorted geographically. (595301)

 HOSTS.TXT........................Official DDN Internet Host Table. (652121)
 HOSTSERVER-INSTRUCTIONS.TXT......How to use NIC hostname server.  (2727)
 IEN-INDEX.TXT....................Internet Experimental Notes Index. (20352)
 IHOST-TEMPLATE.TXT...............Template for new host table entries. (1986)
  INTEREST-GROUPS.TXT..............DDN Interest/discussion groups. (264525)
 INTEREST-GROUPS-1.TXT............DDN Interest/discussion groups; (11312)
 INTEREST-GROUPS-2.TXT............continuation of -1 file; (46257)
 INTEREST-GROUPS-3.TXT............continuation of -2 file; (49879)
 INTEREST-GROUPS-4.TXT............continuation of -3 file; (47340)
 INTEREST-GROUPS-5.TXT............continuation of -4 file; (49199)
 INTEREST-GROUPS-6.TXT............continuation of -5 file; (39736)
 INTEREST-GROUPS-7.TXT............continuation of -6 file. (20802)
 INTERNET.GATEWAYS................Official DDN Gateway Table. (6303)
 INTERNET.PINGING.................Info needed to use INTERNET.GATEWAYS. (12398)
 INTERNET-NUMBER-TEMPLATE.TXT.....How to request an internet number. (7861)

 KERMIT-INFO.TXT..................Kermit info and how to get it. (2893)
 KERMIT-NICSERVER.TXT.............NIC Kermit server usage info. (2070)
 KERMIT-TAC-INFO.TXT..............How to use Kermit through a TAC. (3179)
 MIL-CONFIG.TXT...................Config of MILNET hosts (cpu, etc.) (115537)
 MIL-HOST-ADMINISTRATORS-A-L.TXT..MILNET Host Administrators (A-L). (499847)

 MIL-HOST-ADMINISTRATORS-M-Z.TXT..MILNET Host Administrators (M-Z). (499878)
 MIL-HOSTS.TXT....................List of only MILNET hosts taken from 
                                  the host table. (265404)
 MIL-MAILBRIDGE-HOMINGS.TXT.......MILNET mailbridge homings. (10306)
 MIL-NSC-TEMPLATE.TXT.............Template for NSCs and their alternates
                                  to use when informing the NIC of 
                                  changes. (6488)
 MIL-NSC.TXT......................MILNET Node Site Coordinators. (79551)
 MIL-PSN-COORD.TXT................MILNET NSCs & Host Administrators. (190970)
 MIL-TACACS-INSTRUCTIONS.TXT......User registration instructions for
                                  Host Administrators. (13843)

 MMM-nn.TXT.......................Text of Multi-Media Mail documents. (1-27)
 MMM-INDEX.TXT....................Multi-Media Mail documents index. (4137)
 NBSOSI-AGREEMENTS.DOC............Pointer to PROTOCOLS:NBSOSI-AGREEMENTS.DOC
                                  for NBS OSI Implementors agreement. (315)
 NETWORKS.TXT.....................Networks portion of HOSTS.TXT.
 NIC-PUBS.TXT.....................Publications available from the NIC. (7547)

 NSC-HADMIN-DUTIES.TXT............Role of NSC and Host Administrator. (8779)
 NUG.DOC..........................DDN New User Guide, online version. (156789)
 OSDIR-1.TXT......................Pointer to PROTOCOLS:OSDIR-1.TXT for Office
                                  of Secretary of Defense Memo. (133)
 OSDIR-2.TXT......................Pointer to PROTOCOLS:OSDIR-2.TXT for Office
                                  of Secretary of Defense Memo. (133)
 OSDIR-3.TXT......................Pointer to PROTOCOLS:OSDIR-3.TXT for Office
                                  of Secretary of Defense Memo. (133)

 OSDIR-4.TXT......................Pointer to PROTOCOLS:OSDIR-4.TXT for Office
                                  of Secretary of Defense Memo for DDN
                                  approval of X.25 protocol. (133)
 OSDIR-5.TXT......................Pointer to PROTOCOLS:OSDIR-5.TXT for Office
                                  of Secretary of Defense Memo. (133)
 PROTOCOLS-DOD.BIB................text version of bibliography of recent
                                  articles on TCP, IP, X.25, TP-4, OSI and
                                  other protocol stds. (16014)
 PROTOCOLS-DOD.PS.................postscript version of bibliography of recent
                                  articles on TCP, IP, X.25, TP-4, OSI and
                                  other protocol stds. (23984)
 RESPONSIBLE-PERSONS.TXT..........Responsible Persons, by organization. (17432)
 
 RFC-BY-AUTHOR.TXT................RFC Index sorted by Author. (18590)
 RFC-BY-TITLE.TXT.................RFC Index sorted by Title. (46496)
 RFC-INDEX.TXT....................Index to Request-For-Comments. (125843)
 RFC-SETS.TXT.....................List of RFC sets. (9226)
 ROOT-SERVERS.TXT.................List of 5 root servers and their network
				  addresses. (681)

 SENDMAIL-CF-DOC.TXT..............Sendmail config. documentation. (6294)
 SENDMAIL-GENERIC.TXT.............Sendmail for hosts using both Internet and 
                                  UUCP. (12047)
 SENDMAIL-INTERNET-GENERIC.TXT....Sendmail for Internet-only hosts. (10152)
 SIMTEL20.ARCHIVES................Information on public-domain software at 
				  SIMTEL20. (25991)

 TAC-LOCATION.TXT.................List of TACS sorted geographically. (99688)
 TAC-PHONES.LIST..................Pointer to USA-TAC-PHONES.TXT.
 TAC-USER.DOC.....................How to order the TAC Users' Guide. (675)
 TEST.FTP.........................Sample file for FTP practice. (1162)
 TP4-MEMO.TXT.....................DoD memo on transition to OSI TP4. (3173)
 USA-TAC-PHONES.TXT...............Some U.S. MILNET/ARPANET TAC phone numbers
                                  by location. (27967)
 USER-TEMPLATE.TXT................MILNET/ARPANET user registration info. (6355)

 VENDORS-GUIDE.DOC................TCP/IP Vendors Guide, online ver. (549539)
 VENDORS-TEMPLATE.TXT.............Template for TCP/IP implementors. (1689)
 VIRUS-PATCH.TXT..................Fix to virus affecting UNIX and SUN systems.
 WBS-NOTES-INDEX.TXT..............Index to WideBand Satellite Notes. (4760)
 WHAT-THE-NIC-DOES.TXT............Description of Network Info. Ctr. (8112)

 WHO-DDN.TXT......................Names, phones, mailboxes for DDN PMO. (16419)
 WHOIS-INFO.TXT...................Info for system managers & programmers
                                  explaining NIC WHOIS/NICNAME service. (399)
 X25.DOC..........................DDN X.25 Host Interface Spec. (109537)
 
******************************************************************************

[ NETINFO:MIL-TACACS-INSTRUCTIONS.TXT ]                        [ 2/86, APP ]



               INSTRUCTIONS FOR NETWORK USER REGISTRATION


I.  BRIEF OVERVIEW

   The Defense Data Network Defense Communications Systems (DCS) and the
   Defense Advanced Research Projects Agency (DARPA) have authorized the
   DDN Network Information Center (NIC) to register users on the MILNET and
   the ARPANET and to issue MILNET TAC Access Cards.  The NIC maintains
   the user registration information in the NIC WHOIS Database.  It is the
   intent of the DDN DCS that all network users be registered in the
   WHOIS Database.  This database serves as an online "white pages"
   service, and is also used to produce a hardcopy DDN Directory
   (formerly the ARPANET Directory).  The Host Administrator of each
   host is responsible for registering the users of that host, and for
   authorizing individual account holders to access that host via
   MILNET TACs.  In order to do this, the Host Adminstrator must be
   registered in the WHOIS database and have a network mailbox.  This
   file describes the procedure by which you, as a Host Administrator,
   can register your users and authorize them to access the network
   via MILNET TACs.

II.  GUIDELINES AS TO WHO MAY BE A REGISTERED USER OF THE MILNET/ARPANET

   Users of the DDN network should be engaged in U.S. government business or
   research, or should be actively involved in providing operations or
   system support for government-owned or government-supported
   MILNET/ARPANET computer communications equipment.  Any MILNET or
   ARPANET user with a valid account on a network host may be included
   in the NIC WHOIS Database.

   The intent of the DDN DCS is to let the local hosts manage themselves
   responsibly within the guidelines set down by the government.  In
   accordance, each Host Administrator is responsible for users that he
   or she has authorized to use the network.  The DDN DCS will work with
   the Host Administrators should any problems arise.

III.  USERS REQUESTING ACCESS TO MILNET TACS

   The MILNET TAC Access System (TACACS), which became operational in
   February 1984, controls access to the network by a TAC login
   procedure.  In order to access the network via a MILNET TAC, each
   individual user must have a TAC Access Card issued by the NIC.  In
   order to receive a TAC Access Card, each individual user must by
   registered at the NIC and authorized for TAC access by the Host
   Administrator.

   Users who request MILNET TAC access constitute a special subset of
   registered  users.  The DDN DCS requires that these users be
   individually screened and approved by the authorizing Host
   Administrator.  Also, no one will be given MILNET TAC access without
   first having a valid account on a MILNET/ARPANET host.  The NIC has
   adopted the policy that a MILNET TAC user is "authorized" if the user
   template indicating a need for MILNET TAC access comes to the NIC
   from the authorizing Host Administrator's mailbox.
 
IV.  REGISTERING USERS

   Use the template in Section X to register individuals with accounts
   on your host.  Complete a template for each individual and separate
   the templates by a blank line.  Fill in all the relevant fields
   following the guidelines provided under Section IX.  It is important
   that you use the NIC template and try to adhere to the same data
   entry style as we have used.  This will allow us to automatically
   input the data into our database, and will minimize the amount of
   editing required.  We will not accept data other than in the template
   form specified.

   You may send blank templates to your users to fill out.  Have them
   return the filled-in templates to you.  Accumulate them into a single
   file.  Review the lists (as you are responsible for the
   authorization of registered users on your host), and send us the
   files as messages to the mailbox,  REGISTRAR@NIC.DDN.MIL.  (See Section
   VIII for further discussion on submitting the templates.)

V.  OBTAINING LISTS OF USERS CURRENTLY IN THE NIC DATABASE

   You may request from the NIC a file of templates of individuals
   currently registered in the NIC WHOIS Database whose primary login
   name is on your host.  The file can be pulled over to your host via
   FTP, updated and returned VIA NETWORK MAIL to
   REGISTRAR@NIC.DDN.MIL.  To delete a user from the database, fill
   in the "Delete" field in the user's template.  DO NOT DELETE the
   template itself.  To add a user to the database, fill out the
   template included under Section X.  Complete a template for each new
   individual.  You can add these to the corrected entries or send them
   as a separate list, whichever you prefer.

VI.  DELETING USERS FROM THE DATABASE

   When a user's account is deleted from your host, the user's record
   should be deleted from the WHOIS Database.  This can be accomplished
   by filling in the "Delete" field in the user's template as described
   in Section V, or by sending a brief network message to
   REGISTRAR@NIC.DDN.MIL giving the user's full name and account name. 
   If a user who has been issued a TAC Access Card is deleted from the
   database, the NIC will automatically invalidate the user's card after
   a number of weeks.  The time delay in invalidating the card is
   intended to provide continued network access for users who are moving
   their accounts to a new host.

VII.  USERS WITH ACCOUNTS ON MORE THAN ONE HOST

   A user should ideally be authorized by the Host Administrator of the
   user's "primary" host, where "primary" is defined as the "home" host
   or the host on which the user has an account to do the primary work
   for which he or she is authorized to use the network.  Some users
   will have several legitimate accounts, in which case the "primary"
   host will probably be the one on which they receive electronic mail,
   or the one which they themselves identify as their "home" host.

   If users do have multiple accounts on more than one MILNET/ARPANET
   host, and if each Host Administrator fills in a template for every
   user on his or her host, the NIC may well receive multiple templates
   for some users.  We are prepared to resolve any resulting
   duplication.
    If a user tells you that a template has already been filled in for
   him or her by another Host Administrator, do not fill in another
   template unless you are sure that your host is the primary host for
   that user.  If you are in doubt or don't know, check with the user.
   The NIC will screen for duplication.

   If the user does not require MILNET TAC access, the template need not
   come from the authorizing Host Administrator's mailbox.  However, as
   stated above, the Host Administrator is responsible for the
   appropriateness of all use of the network by users accessing the network
   from his or her host.  Therefore, it is important that the
   "Authorizing Host" field reflect accurately the host which is the
   "home" host or on which the user is doing his or her primary work.

VIII.  ONLINE MAIL ADDRESS FOR COMPLETED TEMPLATES

   Please send user registration templates in a network message to:

      REGISTRAR@NIC.DDN.MIL

   Remember, if users require MILNET TAC access, the list of templates
   MUST be sent to us from the Host Administrator's mailbox.  As stated,
   this is our guarantee that the users on this list are authorized to
   have MILNET TAC access.

   Please send us all the templates via network mail.

   If the list is too long for your mail system to process, you may
   break the lists arbitrarily (between templates) and send them as a
   set of messages.  If  you do break up the list, please indicate in
   the subject field of each message:  Part 1 of 4, Part 2 of 4, etc.
   To assure that the NIC mail system will be able to process your
   message, do not send a message of over 50,000 characters.

IX.  SPECIFIC INSTRUCTIONS FOR EACH TEMPLATE FIELD

   If all users or a group of users in your list will have identical
   data in any field (i.e., same text of address, phone number,
   authorizing host, etc.),  please enter the full text of the field in
   the first template of the group in the list.  You may then indicate
   that this information is to be repeated by simply entering "*" as the
   text of that field in subsequent templates, (* =  ditto).  The "*"
   may be used only in the following fields:

      U.S. MAIL ADDRESS:
      PHONE:
      AUTHORIZING HOST:
      PRIMARY LOGIN NAME:
      PRIMARY NETWORK MAILBOX:
      TERMINATION DATE:

   FULL NAME:

   The name may be entered in any of the following formats:

      Lastname, Firstname I.
      Lastname, Firstname
      Lastname, I. Middlename
      Lastname, Firstname I., Jr.
      Lastname, Firstname I., III

      where "I." = an initial

      Do not include military rank or professional titles.
 
   U.S. MAIL ADDRESS - some standard procedures:

      The name of the organization or university should appear on the
      first line.  Do not use acronyms for the name of the organization.
      The second line may contain information such as the department
      name, code, or attention line, followed by a line containing the
      building name or number, room number if you wish to include any of
      these.  The next line should contain the street address or Post
      Office Box.  The last line of the address field should contain the
      city, state and zip code.  If you commonly use a 9 digit zip code,
      enter that.

      DO NOT USE ANY ABBREVIATIONS OR ACRONYMS, with the exception of

         Incorporated.......Inc.
         Limited............Ltd.
         Corporation........Corp.
         Company............Co.
         Post Office Box....P.O. Box

      Separate lines of the address by a carriage return.

   PHONE:  

      Up to four phone numbers are allowed.  Acceptable formats are:

      U.S. numbers

      (123) 456-7890
      (123) 456-7890 ext 123
      (123) 456-7890 (AV) 567-7890
      (123) 456-7890 (AV) 567-7890 (FTS) 667-7890
      (123) 456-7890 or 456-0987
      (123) 456-7890 or 456-0987 (AV) 567-7890 or 567-0987

      Overseas numbers

      [49] 711-123456 or (AV) 420-1234 or (M) 8765-1234 (For overseas
      numbers, give number through country code with country code in
      brackets.)

   AUTHORIZING HOST:

      This is the name of the host which the user considers his or her
      "home" host, or on which the user is doing the primary work for
      which he or she is authorized to use the MILNET or ARPANET.

      Enter the OFFICIAL HOSTNAME rather than an approved nickname.

   PRIMARY LOGIN NAME:

      This is the primary login name/username/directory name of the
      user on the authorizing host.

      If the login name is a part of the security system on your host
      and therefore should be kept secret, do not enter it in this
      field.

      The primary login name may be a group directory name if it is the
      only one the individual uses.
 
   PRIMARY NETWORK MAILBOX:

      This is the mailbox where this individual prefers to receive
      mail.  This may or may not be his or her primary login name on
      your host.  If mail addresses are case dependent on your host,
      specify the mailbox string accordingly.  Otherwise enter the
      string in upper case.

      Separate the username and hostname parts of the mailbox by "@".

      Format:  USERNAME@HOSTNAME, e.g. SMITH@SRI-NIC

      For those hosts whose official hostname is a Fully Qualified
      Domain Name (FQDN), enter the FQDN in the hostname part of the
      mailbox.  The FQDN is preferred, as in:  SMITH@AI.AI.MIT.EDU

   MILNET TAC ACCESS? (y/n):

      For a user to be authorized for MILNET TAC access, this field must
      be filled in with "y" or "yes".  This is the means by which you, as
      Host Administrator, indicate to us that this user is authorized
      for MILNET TAC access and will require a MILNET TAC Access Card.
      A TAC Access Card will be automatically generated for each
      individual whose template contains "y" or "yes" in this field,
      providing that the template is sent to us from the Host
      Administrator's mailbox.

   TERMINATION DATE:

      The DEROS date (Date Eligible for Return from Overseas) for military
      users, estimated date of graduation for students, estimated
      elapse date for temporary users is requested here for use on
      military hosts.  Others may use the field if they wish.  It is
      not currently used in maintenance of the WHOIS database and will
      not cause automatic deletion of records from the database.

      Format:  MO/YR, e.g., 10/83, 02/84

   HANDLE:

      The handle is the unique identifying label for the record.

      This field appears in templates of currently registered users.

         DO NOT ALTER THIS FIELD.

      This field does not appear in the blank template.  Do not specify
      a handle for the ADDITIONS.  Our program will automatically
      generate a unique identifier (handle) for each individual
      template.

   DELETE? (y/n):

      If the individual no longer has a login account on your host, mark
      this field with a "y" or "yes".  DO NOT DELETE THE WHOLE TEMPLATE.
 
X.  SAMPLE BLANK TEMPLATE

   FULL NAME:
   U.S. MAIL ADDRESS:
   PHONE:
   AUTHORIZING HOST:
   PRIMARY LOGIN NAME:
   PRIMARY NETWORK MAILBOX:
   MILNET TAC ACCESS? (y/n):
   TERMINATION DATE:
 

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

[ NETINFO:USER-TEMPLATE.TXT ]                              [ 6/88, SS ]

                 PROCEDURE FOR MILNET/ARPANET REGISTRATION

This file contains information for registering individual users in the
official MILNET/ARPANET User Registration (WHOIS) Database which is
maintained by the DDN Network Information Center (DDN NIC) on SRI-NIC.  A
user registration template has been created to standardize the registration
procedure and guarantee that the DDN NIC will receive complete information
about each user.  This file contains instructions for filling in the User
Registration template, instructions for sending the template to the DDN
NIC, a sample template, and a blank template.

I.  GUIDELINES AS TO WHO MAY BE A REGISTERED USER OF THE MILNET/ARPANET

Any MILNET or ARPANET user with a valid account on a network host may be
included in the NIC WHOIS Database.  Users of the network should be engaged
in U.S. government business or research, or should be actively involved in
providing operations or system support for government-owned or
government-supported MILNET/ARPANET computer communications equipment.


II.  HOW TO FILL IN THE USER REGISTRATION TEMPLATE

Using an editor of your choice, create a file containing the blank
template and fill in all relevant fields.  Each field should begin on a new
line.  Detailed instructions for filling out the template are given below
under SPECIFIC INSTRUCTIONS FOR EACH FIELD.

214
III.  USERS REQUESTING ACCESS TO MILNET TACS

If you require TAC access, please contact your Host Administrator.

You can determine the name and network mailbox of your Host 
Administrator by consulting the files

      NETINFO:MIL-HOST-ADMINISTRATORS-A-L.TXT
      NETINFO:MIL-HOST-ADMINISTRATORS-M-Z.TXT
      NETINFO:ARPA-HOST-ADMINISTRATORS.TXT

on the SRI-NIC machine.  These files can be FTPed to your host.

Alternatively, you may access the WHOIS/NICNAME Server to receive host
information online, including the name and network mailbox of your Host
Administrator, by executing the command:

      WHOIS HOSTNAME<Return> (where "hostname" is the name of your host)


IV.  WHERE TO SEND THE COMPLETED TEMPLATE

The completed template should be sent to REGISTRAR@NIC.DDN.MIL.
 V.  SPECIFIC INSTRUCTIONS FOR EACH TEMPLATE FIELD

   FULL NAME: 

The name may be entered in any of the following formats:

      Lastname, Firstname I.
      Lastname, Firstname
      Lastname, I. Middlename
      Lastname, Firstname I., Jr.
      Lastname, Firstname I., III

      where "I." = an initial

      Do not include military rank or professional titles.

   U.S. MAIL ADDRESS - some standard procedures:

   Line 1: The name of your organization; do not use acronyms.
   Line 2: Information such as the department name, code, or attention line.
   Line 3: (optional) The building name or number, room number).
   Line 4: Your street address or Post Office Box.
   Line 5: City, state and zip code.  If you commonly use a 9 digit zip
           code, enter that.

      DO NOT USE ANY ABBREVIATIONS OR ACRONYMS, with the exception of

         Incorporated.......Inc.
         Limited............Ltd.
         Corporation........Corp.
         Company............Co.
         Post Office Box....P.O. Box

      Separate lines of the address by a carriage return.

   PHONE:

      Up to four phone numbers are allowed.  Acceptable formats are:

      U.S. numbers

      (123) 456-7890
      (123) 456-7890 ext 123
      (123) 456-7890 (DSN) 567-7890
      (123) 456-7890 (DSN) 567-7890 (FTS) 667-7890
      (123) 456-7890 or 456-0987 (DSN) 567-7890 or 567-0987

      Overseas numbers

      [49] 711-123456 or (DSN) 420-1234 or (M) 8765-1234
      (For overseas numbers, specify the country code in brackets.)

   AUTHORIZING HOST:

      This is the name of the user's "home" host, or on which the user
      is doing the primary work for which he or she is authorized to
      use the MILNET or ARPANET.

      Enter the OFFICIAL HOSTNAME rather than an approved nickname.

   PRIMARY LOGIN NAME:

      This is the primary login name/username/directory name of the
      user on the authorizing host.
 
      If the login name is a part of the security system on your host 
      and therefore should be kept secret, do not enter it in this 
      field.

      The primary login name may be a group directory name if it is the
      only one the individual uses.

   PRIMARY NETWORK MAILBOX:

      This is the mailbox where this individual prefers to receive
      mail.  This may or may not be his or her primary login name on
      the host.  If mail addresses are case dependent on your host,
      specify the mailbox string accordingly.  Otherwise enter the
      string in upper case.

      Separate the username and hostname parts of the mailbox by "@".

      Format:  USERNAME@HOSTNAME
      Example: SMITH@NIC.DDN.MIL

      For those hosts whose official hostname is a Fully Qualified 
      Domain Name (FQDN), enter the FQDN in the hostname part of the 
      mailbox.  The FQDN is preferred.

      Example: Smith@AI.AI.MIT.EDU

   TERMINATION DATE:

      The DEROS date (Date Eligible for Return from Overseas) for military 
      users, estimated date of graduation for students, estimated 
      elapse date for temporary users.

      This field was requested for use on military hosts.  Others may 
      use the field if they wish.

      Format:  MO/YR 
      Example: 10/87 

=======================================================================
SAMPLE USER REGISTRATION TEMPLATE
=======================================================================

FULL NAME: Kahn, Susan
U.S. MAIL ADDRESS: SRI International
Telecommunication Sciences Center
Network Information Center
333 Ravenswood Avenue
Menlo Park, California 94025
PHONE: (415) 859-6111
AUTHORIZING HOST: SRI-NIC
PRIMARY LOGIN NAME: SKAHN
PRIMARY NETWORK MAILBOX: SKAHN@NIC.DDN.MIL
TERMINATION DATE:
 
=======================================================================
USER REGISTRATION TEMPLATE
=======================================================================

FULL NAME:
U.S. MAIL ADDRESS:
PHONE:
AUTHORIZING HOST:
PRIMARY LOGIN NAME:
PRIMARY NETWORK MAILBOX:
TERMINATION DATE:

-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 20:45:12 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcasting Adreess and Subnets

In article <9003262150.AA14999@asylum.sf.ca.us> dab@asylum.sf.ca.us (Dave Bridgham) writes:
    I agree that having 255.255.255.255 mean send this packet to all hosts
    on all networks is a stupendously bad idea.

I agree, too.  I wrote in RFC950:
   When a datagram is broadcast, it imposes a cost on every host that
   hears it.  Therefore, broadcasting should not be used
   indiscriminately, but rather only when it is the best solution to a
   problem.
Broadcasting is a blunt tool, and anyone contemplating swinging it too
widely should be locked up as a danger to the community.
    
    [Actually I think that being able to send a broadcast to all
    subnets of a network is a bad idea but fortunately I've not noticed
    anyone trying to push protocols that depend on it.]

Since I wrote RFC922, I've had a change of heart; I agree that multi-
subnet broadcasts are a bad idea.  I've heard from some people that
RFC1009 can be read to require their support, and also to require that
if supported that one can configure them to be blocked; my reading of
RFC1009 is that gateways are not required to support them.  At any rate,
this is clearly an issue for the Router Requirements Working Group, and
I hope that they rectify my error.
    
    Since 255.255.255.255 wasn't going to mean all hosts everywhere, it was
    defined to mean the one thing that broadcasts are maybe useful for
    anyway; broadcast on the local wire, whatever it is.

More specifically:  255.255.255.255 was chosen as the appropriate address
(instead of something depending on the local network number) so that it
would be possible to use it during the host-configuration process.  Also,
by defining it to mean "this wire" we foreclosed on any possible use of
this address to mean "the universe".  Note that RFC1009 specifically
prohibits a router from forwarding such a packet under any circumstances.

And this definition has not been abolished; see RFC1122 section 3.3.6.
RFC1122 suggests that 255.255.255.255 be used in essentially all cases
where broadcasting is done at all; I agree.  The only complexity comes
from originating a broadcast from a multi-homed host; should the host
send copies of a dst=255.255.255.255 datagram on each of its connected
(broadcast-capable) interfaces?  RFC1122 "takes no stand on the issue"
but I would say "yes"; otherwise, applications that do need to use
broadcasting are faced with a more complex choice, and they will
probably get it wrong sometimes.

-Jeff

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 90 22:26:41 GMT
From:      jeff@hpctdkp.HP.COM (Jeff Hughes)
To:        comp.protocols.tcp-ip
Subject:   ICMP usage

Are there any Gateway experts out there who can give me some
information on ICMP and its many uses. I have heard rumors
that the ICMP source quench message is rarely used (successfully)?

I also need to know if there are any gateways/hosts that do not
speak ICMP. Are there any commonly occuring ICMP problems??
Are there some ICMP messages which are almost never used??
Any info would be appreciated.

jeff@hpctdlb.hp.COM

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Apr 90 19:16:14 +0200
From:      zrfp0128%awssn3.rus.uni-stuttgart.de@CUNYVM.CUNY.EDU (Joerg Hertzer)
To:        TCP-IP%SRI-NIC.ARPA@RUSVM1.rus.uni-stuttgart.de
Subject:   Re:  Diskless Sun Booter
>Hi, I am faced with the following problem:  I can get a diskless Sun
>3/50 for $2000, but I need disks for it.  A shoebox with a 150MB disk
>costs $2500 (used!!!).

May be it would be best to buy a disk for your sun elsewhere.
There are disk subsystems with case and with power supply
fitting to Suns, but much cheaper as shoeboxes.

I know some dealers for that in West Germany and I assume it will
be easy to find the same in other countries by reading ad's
in Computer Magazines.


Joerg
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 00:14:05 GMT
From:      kirkd@ism780c.isc.com (Kirk Davis)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   *** Summary: SLIP Header Compression

Hi again,
    Sorry for the delay, here's the summary I promised on SLIP.

    First off, SLIP header compression is described in RFC 1044.
It's one of the more enjoyable RFC's I've read.
It's written by Van Jocobson @ UCB and includes code examples.
The code is fairy portable, and implementing it was fairy easy even
on a streams based version of SLIP.

    Second, SLIP is being replaced by PPP (Point to Point Protocol).
The folks at UCB are working on a BSD version that should
be out sooner or later. Also there is a PPP version of for 
KA9Q out now that includes Van Jocobson's header compression 
(see below).

Here is a list of ftp'able stuff I've found/gotten replies on:

ftp.ee.lbl.gov (128.3.254.168)

	RFC 1044 (ascii & postscript)
	beta slip header compression code & utils
	at some point a version of PPP for BSD

ucdavis.edu (128.120.2.1)

	KA9Q ppp with header compression (in dist/ppp directory)
	A version of dialup SLIP.

icarus.riacs.edu (128.102.16.8)

	SunOS version of SLIP, streams based.

There seems to be quite a few versions of dialup slip. None that
I have run across seem to be demand dial however.

I did hear about a version done by CSNET, but I don't think it was
public domain. Anyone know of any others???

Tnx to all that replied.
Kirk Davis	Interactive Systems Corp.	(kirkd@ism.isc.com)

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 02:35:30 GMT
From:      wiltzius@lll-lcc.UUCP (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   Gigabit throughput


I'm interested in issues regarding very high-speed
(gigabits/sec) networks - LANs, MANs and WANs.  Any
pointers to people, literature and proceedings that
may be relevant to this topic would be much appreciated.

Thanks.
  Dave Wiltzius (wiltzius@lll-lcc.llnl.gov)

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 03:16:28 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: tftp,anonymous ftp

Geez, It looks as if there are some history lessons in order. TFTP was
invented in about 45 minutes to allow us system managers to ship
stuff to each other without havin tohave the FULL FTP up and running.
This was a "DEBUG MODE" hack.  We never intended it to be much more 
useful.  It should die.

Dan

PS.  My 'umble opinion only -- I'm only giving the historical
perspective here.  Others may have found more use for this DANGEROUS
protocol.
-------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 04:30:33 GMT
From:      earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

Am I the only Luddite out here that thinks that High Schools should not be
on the Internet?  Why not let High Schoolers continue to do what they should
be doing - being High Schoolers, growing up a little, and doing something
useful in their spare time.  Leave the Internet Black Hole for College, when
little Johnny/Jeannie is not only more knowledgable/mature/responsible, but
has more control over his/her time-slicing.  I'd rather see someone turn into
a Compu-troll (if they have to) in college than while still in High School.
(As for Jimmy/Janey Brainiac, let them take classes at their local colleges
 and fall into the Black Hole via that route.)

Donning the Asbestos (and sorry for the TCP/IP bandwidth waste),

--
	Greg Earle
	Sun Microsystems, Inc. - JPL on-site Software Support
	earle@poseur.JPL.NASA.GOV	(direct)
	earle@Sun.COM			(indirect)

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 09:10:48 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   software implementation of Ethernet CRC

/*
 * This code implements the AUTODIN II polynomial used by Ethernet,
 * and can be used to calculate multicast address hash indices.
 * It assumes that the low order bits will be transmitted first,
 * and consequently the low byte should be sent first when
 * the crc computation is finished.
 * The variable corresponding to the macro argument "crc" should
 * be an unsigned long and should be preset to all ones for Ethernet
 * use.  An error-free packet will leave 0xC704DD7B in the crc.
 *			Spencer Garrett <srg@quick.com>
 */

#define CRC(crc, ch)	 crc = (crc >> 8) ^ crctab[(crc^(ch)) & 0xff]

/* generated using the AUTODIN II polynomial	0x104C11DB7 ==
 *	x^32 + x^26 + x^23 + x^22 + x^16 +
 *	x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x^1 + 1
 */
unsigned long crctab[256] = {
	0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
	0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
	0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
	0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
	0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
	0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
	0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
	0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
	0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
	0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
	0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
	0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
	0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
	0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
	0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
	0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
	0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
	0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
	0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
	0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
	0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
	0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
	0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
	0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
	0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
	0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
	0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
	0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
	0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
	0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
	0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
	0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
	0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
	0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
	0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
	0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
	0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
	0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
	0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
	0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
	0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
	0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
	0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
	0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
	0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
	0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
	0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
	0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
	0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
	0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
	0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
	0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
	0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
	0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
	0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
	0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
	0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
	0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
	0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
	0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
	0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
	0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
	0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
	0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d,
};

#include <stdio.h>

main()
{
	unsigned long crc = 0xFFFFFFFF;

	int i;

	while (scanf(" %x", &i) == 1)
		CRC(crc, i);
	printf("crc 0x%08x\n", crc);
}

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 12:47:53 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet


Your assuming that the focus is on the students.  Another focus might be
the teachers.

Marty
--------------

 Am I the only Luddite out here that thinks that High Schools should not be
 on the Internet?  Why not let High Schoolers continue to do what they should
 be doing - being High Schoolers, growing up a little, and doing something
 useful in their spare time.  Leave the Internet Black Hole for College, when
 little Johnny/Jeannie is not only more knowledgable/mature/responsible, but
 has more control over his/her time-slicing.  I'd rather see someone turn into
 a Compu-troll (if they have to) in college than while still in High School.
 (As for Jimmy/Janey Brainiac, let them take classes at their local colleges
  and fall into the Black Hole via that route.)

 Donning the Asbestos (and sorry for the TCP/IP bandwidth waste),

 --
 	Greg Earle
 	Sun Microsystems, Inc. - JPL on-site Software Support
 	earle@poseur.JPL.NASA.GOV	(direct)
 	earle@Sun.COM			(indirect)

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 13:54:16 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.2BSD lpr spec exists.

In article <12680@mcdphx.phx.mcd.mot.com> kjj@varese.UUCP (Kevin Johnson) writes:

   In article <9003291950.AA07210@sun.soe.clarkson.edu.soe> nelson@SUN.SOE.CLARKSON.EDU (Russ Nelson) writes:
   >Five years ago, Shawn Routhier write a document that describes the lpr
   >protcol.  I found that document in husc6.harvard.edu:/pub/pcip/doc.tar.Z:/doc/lprspec.txt.
   >I'll put it sun.soe.clarkson.edu:/pub/ka9q/lprspec.txt.

   How big is that doc?  Could it be posted on 'the net'?

If you aren't on the Internet (poor you), you can fetch it either through
BITFTP@PUCC.BITNET, or through our archive-server@sun.soe.clarkson.edu.
Send either one a message consisting of the single word "help".
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
Clarkson will be featured on PBS's Computer Chronicles this week.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 14:51:49 GMT
From:      smb@ulysses.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: tftp,anonymous ftp

In article <9003290354.AA00580@Jester.CC.MsState.Edu>, peters@CC.MSSTATE.EDU (Frank W. Peters) writes:
> I don't know of any common use for the ability to write files with 
> tftp.  There is absolutely no way to give write permission even a
> semblance of security so I wouldn't recommend using it.

Cisco routers can upload their configuration using tftp.  When I need
to do this -- to make a backup, for example -- I create the file,
enable tftp, make the backup, and then disable everything.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 17:00:10 GMT
From:      jeff@hpctdkp.HP.COM (Jeff Hughes)
To:        comp.protocols.tcp-ip
Subject:   ICMP types


Are there any ICMP message types aside from the ones defined in RFC792
and RFC950??

jeff@hpctdlb.hp.COM

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 17:23:21 GMT
From:      stewart@xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   software implementation of Ethernet CRC

Thanks.  I passed it along to our guy that asked me for it.

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 17:32:45 GMT
From:      tmt@osf.org
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with AIX "illegal protocols" ?

> jon postel
> the code in question is registered (91 = LARP), see RFC-1060 page 8.
> However, i'd really like to see an explanation of why any machines crash
> when a datagram with a protocol type they didn't know about before comes
> along.  Anyone have the story?

I'd say the story is that the receiver sees an ethertype which looks like
an 802.3 length field, goes off to look for the SSAP and DSAP or 91 bytes
of packet and gets very confused. Granted the machine shouldn't crash!
Most HP's support both Ethernet type 2 and 802.3 framing, and the fact that
the patch is in ip_input is most curious. Apparently the kernel is handing
up the LARP packet to the IP handler, not a good idea.

Perhaps the IANA or someone can provide the story on the history of the
LARP type? For instance why it's using a value in conflict with 802.3?

Tom Talpey
tmt@osf.org

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 18:28:03 GMT
From:      LARSON@CRVAX.SRI.COM (Alan Larson)
To:        comp.protocols.tcp-ip
Subject:   re: MX Records

Recently I wrote:
>> Suprisingly, it is a technical error for the MXer of highest preference
>> to not be the host itself.  This would result in an empty MX list after
>> removing irrelevant RRs in the MXer of highest preference.  This is an
>> error condition, although it is noted that "974 points out that "extremely
>> persistent mail systems might want to try a delivery to REMOTE's address..."

Michael Stein caught me for not stating one of my assumptions when he asked:

>What about the case where there are "non-internet" paths to
>the host from the MXer of highest preference?

Michael is quite correct in noting this.  RFC974 expects that the
MXer of highest preference (which it calls LOCAL) will know how to
deliver the mail without resorting to the domain name system.
My assumption was that the last hop to the final destintion host was
also a DNS resolved internet hop, which is clearly not always the case.

I have attached the relevant paragraph from RFC974 at the end of this
message for those who do not have a copy.

	Alan



   After removing irrelevant RRs, the list can again be empty.  This is
   now an error condition and can occur in several ways.  The simplest
   case is that the WKS queries have discovered that none of the hosts
   listed supports the mail service desired.  The message is thus deemed
   undeliverable, though extremely persistent mail systems might want to
   try a delivery to REMOTE's address (if it exists) before returning
   the message. Another, more dangerous, possibility is that the domain
   system believes that LOCAL is handling message for REMOTE, but the
   mailer on LOCAL is not set up to handle mail for REMOTE.  For
   example, if the domain system lists LOCAL as the only MX for REMOTE,
   LOCAL will delete all the entries in the list.  But LOCAL is
   presumably querying the domain system because it didn't know what to
   do with a message addressed to REMOTE. Clearly something is wrong.
   How a mailer chooses to handle these situations is to some extent
   implementation dependent, and is thus left to the implementor's
   discretion.
	
-------

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 18:50:38 GMT
From:      martyne@batcomputer.tn.cornell.edu (Martyne Hallgren)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

In article <9003291833.AA21594@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>
>Also, Richard Mandelbaum of NYSERNet Inc. is working on this
>issue.
>
>Marty
>--------------
>
> Russ:
>
> At the next IETF meeting you might wish to take a moment to speak
> with Martyne Hallgren of Cornell.  She is in the process of putting
> a number of high schools onto the Internet.
>
> Bob



As part of the SUPERQUEST '89 project (a competitive program where high
school teams, composed of a teacher and 3-4 students, compete for the
opportunity to access to and support from the Cornell National
Supercomputer Facility, training in computational science techniques at
Cornell,  and a scientific workstation configuration from IBM), four
high schools were provided with access to the Internet.  The high schools
are Montgomery Blair High School, Silver Springs, MD, North Carolina School of
Science and Technology, Durham, NC, Illinois School of Science and Math,
Aurora (close to Chicago), IL, and Clear Lake High School, Clear Lake (Houston)
 TX.  All four schools have an IP connection, using either SLIP from one of 
the scientific workstations  or a dedicated router connected into their LAN.  

It would not have been possible to bring these high schools on-line with the
cooperation and technical assistance of the folks at the regional networks 
and organizations the high schools finally connected into. They include 
SURANET, SEQUINET and Rice University, and the networking division of 
MCNC and the North Carolina Supercomputer Center and Argonne Labs.  

SUPERQUEST '90 is in full swing and we expect to offer the same level of
access to the CNSF this year.


Martyne  



************************************************************************
*  Martyne M. Hallgren       Internet:  martyne@tcgould.tn.cornell.edu *
*  Technical Advisor         Bitnet:    martyne@crnlthry               *
*  Cornell Theory Center     Phonenet:  607-255-9397                   *
*  265 Olin Hall                                                       *
*  Ithaca, NY 14853                                                    *
*                                                                      *
*" The mind, once expanded to the dimensions of larger ideas, never    *
*  returns to its original size."  -Oliver Wendell Holmes              *
************************************************************************

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 19:31:48 GMT
From:      chip@tct.uucp (Chip Salzenberg)
To:        comp.protocols.tcp-ip,comp.unix.xenix
Subject:   Re: Using SLIP with SCO Xenix/Unix

According to jtc@van-bc.UUCP (J.T. Conklin):
>In article <260F7FA9.4661@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>SCO SLIP works *only* with SCO serial drivers.
>
>Not true.

I've had several replies to my original (quoted) article, to the
effect that non-SCO drivers work with SCO SLIP.

My statement was based on the SCO documentation (which was, I admit,
ambiguous) and a test with the Computone Intelliport.  Now I discover
that Computone's So-Called Programmers Who Have Q-Tip Cotton Swabs[tm]
For Brains have done it to me again.

It figures.
-- 
Chip Salzenberg at ComDev/TCT   <chip%tct@ateng.com>, <uunet!ateng!tct!chip>
          "The Usenet, in a very real sense, does not exist."

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 21:07:58 GMT
From:      davew@gvgpsa.gvg.tek.com (David C. White)
To:        comp.unix.ultrix,comp.unix.questions,comp.protocols.tcp-ip
Subject:   UUCP over TCP/IP in Ultrix

I have a couple of applications that require the use of UUCP over
TCP/IP.  However, Ultrix (at least 3.1) does not supply this capability
via uucpd and in looking through the uucico binary, it does not appear
that network links or the 't' protocol are supported.

I talked to the support center and after some head scratching they told
me that uucpd could be found on gatekeeper.dec.com.  They were right
about that, except the header file uucp.h was not there and as far as I
can find out it is not in the public domain (we don't have a source
license).  Even if I could have gotten uucpd to compile I doubt that
the Ultrix version of uucico would support the TCP/IP link.

Does anyone know of anything available that would allow this capability
under Ultrix?  Will uucico be upgraded and uucpd support be in the 4.0
version?  Any pointers would be appreciated.
-----
Dave White	Grass Valley Group, Inc.   VOICE: +1 916.478.3052
P.O. Box 1114  	Grass Valley, CA  95945    FAX: +1 916.478.3887
Internet: davew@gvgpsa.gvg.tek.com 
UUCP: ...!tektronix!gvgpsa.gvg.tek.com!davew

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 90 21:50:19 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: software implementation of Ethernet CRC


Arggh!  The code I recently posted to compute Ethernet CRC's is
correct.  Unfortunately, the comment at the top contains dregs
of an older big-endian implementation.  The value remaining
in "crc" upon receipt of an error-free packet should be 0xdebb20e3,
and the crc should be complemented before being transmitted.
Here's a corrected version:

/*
 * This code implements the AUTODIN II polynomial used by Ethernet,
 * and can be used to calculate multicast address hash indices.
 * It assumes that the low order bits will be transmitted first,
 * and consequently the low byte should be sent first when
 * the crc computation is finished.  The crc should be complemented
 * before transmission.
 * The variable corresponding to the macro argument "crc" should
 * be an unsigned long and should be preset to all ones for Ethernet
 * use.  An error-free packet will leave 0xDEBB20E3 in the crc.
 *			Spencer Garrett <srg@quick.com>
 */

#define CRC(crc, ch)	 (crc = (crc >> 8) ^ crctab[(crc ^ (ch)) & 0xff])

/* generated using the AUTODIN II polynomial
 *	x^32 + x^26 + x^23 + x^22 + x^16 +
 *	x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x^1 + 1
 */
unsigned long crctab[256] = {
	0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
	0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
	0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
	0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
	0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
	0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
	0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
	0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
	0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
	0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
	0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
	0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
	0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
	0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
	0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
	0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
	0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
	0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
	0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
	0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
	0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
	0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
	0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
	0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
	0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
	0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
	0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
	0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
	0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
	0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
	0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
	0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
	0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
	0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
	0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
	0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
	0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
	0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
	0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
	0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
	0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
	0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
	0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
	0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
	0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
	0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
	0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
	0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
	0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
	0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
	0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
	0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
	0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
	0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
	0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
	0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
	0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
	0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
	0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
	0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
	0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
	0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
	0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
	0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d,
};

#include <stdio.h>

main()
{
	unsigned long crc = 0xFFFFFFFF;

	int i;

	while (scanf(" %x", &i) == 1)
		CRC(crc, i);
	printf("crc 0x%08x comp 0x%08x\n", crc, ~crc);
}

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 00:46:00 GMT
From:      kirkd@ism780c.isc.com (Kirk Davis)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: *** Summary: SLIP Header Compression (correction)

In article <40886@ism780c.isc.com> I wrote:
>
>    First off, SLIP header compression is described in RFC 1044.

As someone points out, that should read RFC 1144 not 1044. 
Sorry if I caused anyone any undue grief.

Kirk Davis	Interactive Systems Corp.	(kirkd@ism.isc.com)

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 00:58:03 GMT
From:      9479P@NAVPGS.BITNET (Greg Rassatt)
To:        comp.protocols.tcp-ip
Subject:   Take me off mailing list

Please take me off the tcp-ip mailing list.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 01:19:26 GMT
From:      cjsv@cc.adfa.oz.au (Christopher JS Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: MX Records

In article <638650816.970000.LARSON@CRVAX.SRI.COM> LARSON@CRVAX.SRI.COM
(Alan Larson) writes:
.> Suprisingly, it is a technical error for the MXer of highest preference
.> to not be the host itself.  This would result in an empty MX list after
.> removing irrelevant RRs in the MXer of highest preference.  This is an
.> error condition, although it is noted that "974 points out that "extremely
.> persistent mail systems might want to try a delivery to REMOTE's address..."

Caveat: I haven't read the RFC recently, so I'm not suggesting Alan is wrong
in his interpretation of what is mandated.  My comments are addressed to what
*ought* to be the case.

It is quite often desirable to run diskless or other small machines with
a shared incoming mail spool area on a common server, but with each
machine able to initiate mail.  It is therefore quite possible to have
an MX record for host a.domain pointing to a server b.domain.  Despite
the fact that a.domain may have an IP address, it may not be running an
SMTP daemon.  In that situtation, for the domain I manage, I don't want
the A record to be used. 

Specification of from addresses isn't the point, since much mail comes
other than as the result of a reply.  What *is* necessary is for
b.domain to know that mail addressed to a.domain should be delivered
either locally on b.domain, or via some protocol other than SMTP to some
other place. 

Another point is that a host without an IP address cannot be its own
highest preference MX forwarder.

.> The present system provides for reasonable defaults, and reduces the
.> amount of information stored and transmitted in the DNS in common cases.
.> The current use of an A record implying an MX record is reasonable, and
.> should be retained.

Yes, but

* only where there are no MX records for the host *at all*;

* never by an MX forwarder for the host in question. 

My understanding (of what ought to be) is:

* an MX forwarder for a host (except a highest preference forwarder)
should use MX records (but never A records) to push the mail towards a
highest preference forwarder, or may alternatively choose to use some
protocol other than SMTP (e.g., uucp, ACSnet, ...) which may be an
alternative route to the host bypassing any other MX forwarders;

* a highest preference MX forwarder for a host should never use an A
record to deliver mail for that host, unless explicitly set up to do so,
and even then, only after recognizing the destination as one for which
is it a highest preference forwarder [see note below] -- but in that
case why was the host itself not its own highest preference MX
forwarder?

In other words, a highest preference MX forwarder for a host *must know*
that it has that status, so that it can know to route mail for that host
without using SMTP, or at least without using A records unless
*explicitly configured to do so for that host*.  Other MX forwarders for
a host need not know they have that status, but should not use any A
records, since by definition there still exist higher preference MX
records.  If I specify MX records for a name, I want them obeyed by
*all* mail deliverers.  (So, an MX forwarder should always use MX
records itself.  Specifying a host as an MX forwarder which doesn't
understand MX records itself seems to be pretty silly.)

[Note:] Currently, a wildcard MX is only returned if there are no other
records of any type for that name.  In such a case there aren't any A
records so the above discussion about A records is irrelevant. 

If this is changed, as has been mentioned, so that a wildcard MX is
returned for a name if no explicit MX records exist but without regard
to the existence of any other record types, then I could conceive that a
domain manager might specify a single highest preference MX forwarder
for an entire domain, and then might want to use A records for local
delivery within the domain.  But that is his choice, and everybody else
should use the MX records to deliver to where he said.

When I specify both A and MX records for a name, I mean what I say...

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 01:21:23 GMT
From:      brad@cayman.COM (Brad Parker)
To:        comp.protocols.tcp-ip
Subject:   Re: Help: NFS Mounts over `slip' not working

In article <7624@celit.fps.com> dave@fps.com (Dave Smith) writes:
>In article <883@wrs.wrs.com> hwajin@wrs.wrs.com () writes:
>>In article <1807@tfd.UUCP> kent@tfd.UUCP (Kent Hauser) writes:
>>>Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP 
>>
>>SunOS 3.5 turns the UDP checksum off, which is legal and works okay
>
>Possible, but unlikely.  Direct connect serial links have pretty low error
>...
>What is more likely to be happening is that the packets are just taking too 
>long to come across.  NFS works in a block mode; each read/write involves 

Yes. I think you are correct. I did a lot of work with our NFS client 
using slow links and slow servers. Adjusting the timeouts a retries did
help a lot. However, this is not a good solution. If you get any
retries at all at 9600 baud, you can swamp the link (which is rediculous
if you think about this too hard ;-)

The best results I obtained where when I added Van J's round trip estimator
to the rpc code. My implementation would "clamp" the retransmission to 
keep it from occuring if the time was less than the rtt. Very crude but
extremely effective. (we may be shipping the only adaptive rpc client for
nfs!). I can mount both DN3000 NFS servers (slower than molassas) or suns
over a 9600 baud link with no retramissions (ok, I'm bragging. sorry).

We also added this style of rtt estimator to some appletalk ASP code. We
found it harder to get a good rtt at 2400 baud and below since the times
varied much more in relationship to packet size (but, we fixed that by
attempting to estimate the link speed in bytes/seconds and adjusting
the clamping based on the packet sizes.)

More hot air for the grist mill. (never burn a horse's gift teeth)
-brad
-- 
"such a narley little surf machine..." (either Spot 1019 or the Meat Puppets?)
Brad Parker
Cayman Systems, Inc.		Cambridge, Ma.			brad@cayman.com

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 03:05:10 GMT
From:      ggw@wolves.uucp (Gregory G. Woodbury)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

In article <10045@batcomputer.tn.cornell.edu> (Martyne Hallgren) writes:
>four high schools were provided with access to the Internet. 
>.... North Carolina School of Science and Technology, Durham, NC

	This should be North Carolina High School of Science and Mathematics.
Which is fondly know as S&M High by its family and friends.  It graduates
some real smart cookies.
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 10:16:57 GMT
From:      zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet


>Am I the only Luddite out here that thinks that High Schools should not be
>on the Internet?
 
>	Greg Earle
>	Sun Microsystems, Inc. - JPL on-site Software Support
>	earle@poseur.JPL.NASA.GOV	(direct)
>	earle@Sun.COM			(indirect)

I also am unlucky about that, but I think we should not forbid
any interested people to use the internet, but we should design more secure
network software.

Joerg Hertzer
Computer Center University Stuttgart
West Germany

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 12:46:52 GMT
From:      huitema@mirsa.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip
Subject:   re: MX Records

In article <638650816.970000.LARSON@CRVAX.SRI.COM>, LARSON@CRVAX.SRI.COM
(Alan Larson) writes:

|>Philip writes:
|>
|>	The only time it should be possible to deliver mail to a host
|>	without an MX record is when it is done by the MXer of highest
|>	preference for that destination.
|>
|>Suprisingly, it is a technical error for the MXer of highest preference
|>to not be the host itself.  This would result in an empty MX list after
|>removing irrelevant RRs in the MXer of highest preference.  This is an
|>error condition, although it is noted that "974 points out that "extremely
|>persistent mail systems might want to try a delivery to REMOTE's address..."

If the host has an A record, then the host is reachable directly via the
Internet.
If one does not want to list that host as the MXer of highest preference, it is
probably that one does not want to receive mail directly on that system, but
rather feed the mail through some "central" server. Indeed, there might be some
good reasons for that, like not wanting to receive mail directly on a
PC.. BUT!!

BUT think a bit more. If one does want to receive one's mail on the central
server, or if one want to forward it from the central using some kind of alias
table, why not simply use the name of that central server in the mail
addresses?
Rather than prohibiting mailers to look at A records, Philip should rather
consider cleaning his own house, and not advertise the addresses of PC or work
stations as valid mail addresses!

Christian Huitema

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 15:37:23 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   (none)

I'm trying to find an FTP client for the Mac. The NCSA package I have only
provides an FTP server which of course is useless when one wants to anonymous
FTP to a host on which one does not have a login. Also I am looking for
a POP2 client for the Mac, we have a number of Macs on an AppleTalk network
connected to internet via a Kenitics Fastpath but no way to provide mail
service to them. Any help in either area would be appreciated. Thanks in
advance.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 15:39:24 GMT
From:      wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 erebus.att.com!wcs)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

In article <9003301417.AA26872@ucbvax.Berkeley.EDU> OWEN@DUCVAX.AUBURN.EDU (Larry Owen) writes:
]The Alabama Supercomputer Network has some sort of grant to connect several
](5 or 6 in the first round) high schools to ASN.  ASN is a state-wide
]T1-extended ethernet, supporting both TCP/IP and DECNET, and is connected

My... and I thought it was a big deal when the high school I went to
had a TTY-33 timeshared into a PDP-11 at the University of Delaware.
This could be a good thing if you can find a way to get kids
involved at a level they can handle intellectually, without forcing
too much structure on them - playing around has a lot of value.
			Bill
-- 
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Fax 949-4876.  Sometimes found at Somerset 201-271-4712

# When *everything* is outlawed, only outlaws will have everything!

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 16:02:22 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with AIX "illegal protocols" ?


Lee:

While LARP has an assigned number listed in RFC-1060, i'd not call it
documented, perhaps identified.  Since it is now out causing the public
trouble it would be helpful if the authors of LARP did document it.

--jon.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 16:19:51 GMT
From:      RUBIN%POLYGRAF@GRAF.POLY.EDU (David Rubin)
To:        comp.protocols.tcp-ip
Subject:   Difinitive time server

I am looking for a list of difinitive time servers on the Internet.
I need to find the most accurate time possible.  Does anyone
have a list of difinitive time servers?

Please respond via E-mail...

--
David Rubin                        |     INTERNET: RUBIN@graf.poly.edu
Polytechnic University             |       BITNET: RUBIN@POLYGRAF
Brooklyn, NY                       |

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 16:19:53 GMT
From:      ihm@NRC.COM (Ian H. Merritt)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) says:
>Am I the only Luddite out here that thinks that High Schools should not be
>on the Internet?  Why not let High Schoolers continue to do what they should
>be doing - being High Schoolers, growing up a little, and doing something
>useful in their spare time.  Leave the Internet Black Hole for College, when
>little Johnny/Jeannie is not only more knowledgable/mature/responsible, but
>has more control over his/her time-slicing.  I'd rather see someone turn into
>a Compu-troll (if they have to) in college than while still in High School.
>(As for Jimmy/Janey Brainiac, let them take classes at their local colleges
> and fall into the Black Hole via that route.)
>
>Donning the Asbestos (and sorry for the TCP/IP bandwidth waste),

Hoping in turn that this message doesn't spark a flurry of responses
(in which case, I'd wish to take it offline), I feel compelled to
respond to this.

I for one was using the ARPAnet, in what at the time was a legal gray
area, since about 1975.  At that time, I was in high school, and had
been told by fellow students of a neat little number (TIP) that you
could dial into and connect up to MANY machines.  Also, I was told of
a few at MIT where you could get a guest account for the asking.  I
became familiar with MIT-ITS, a powerful (for the time) if strange
operating system environment, and more importantly, with the MIT
hacking mentality. (Remember what hacking meant until the media
misrepresented it to the masses).  I also was granted guest accounts
at other sites around the network, including one at DEC-MARLBORO, a
TOPS-20 system, with which I also became familiar.  At that time,
there were few unix machines on the net.  Mostly it was PDP-10's
running TOPS-10, Tenex or early versions of TOPS-20.

Thanks in large part to this experience, I went on to work in the
computer industry, and for several years at USC/ISI.  I am now, once
again, working with what is now the internet.

In short, I understand the fears associated with high-schools on the
network and I share some of them.  Part of my concern is for the
general incompetence of the high-school level staff to run an internet
site.  This can be overcome by hiring people with some internet
experience.  The rest of my concern is of course, for the security
risk posed by encouraging students to be on the network.  But to a
significant extent, that very thing at the college level (not much
older than high school kids) contributed to the very formation of this
network.  Carfully monitored, but not to the point of squelching
creativity, I think it might be a positive influence, not only on the
kids, but possibly on the internet itself to begin bring high-schools
on line.

Incidentally, I was not alone in my high-school persuit of the
ARPAnet.  At my school alone, in my grade-level, there were at least
20 others, not to mention those in other grades.  I met students from
accross the nation over the net.  Many of us are now in the industry.
Some have worked at DEC, Cisco, Think, Symbolics; some have since
graduated MIT, Harvard.  You get the idea...

-- 
US Snail:	2380 Rose Avenue; Oxnard, CA  93030  U.S.A. tel. 805-485-2700
InterNet:	ihm@NRC.COM

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 16:24:00 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP


Angela:

See RFC-1055, and see also RFC-1134.

--jon.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 16:35:26 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip,comp.protocol.tcp-ip.ibmpc
Subject:   WD8003 driver bug and possible bug in other drivers for 8390 chip

After much pitch forking, I have found a bug in my WD8003xx ethernet driver
(Beame & Whiteside Software Ltd.). Since this bug seems to be in Western
Digital's sample code, the Clarkson packet driver code and maybe in several
commercial packages, I will share my discovery.

The error manifests itself by placing the driver in an infinite loop with
interrupts enabled. (ie. CTRL-ALT-DEL works, but otherwise the PC is hung).

The error is in the code to handle an overflow condition. The National Spec.
says that the 8390 chip should be stopped, a packet removed from the chain 
(received) and then several bizarre other manipulations. My code, the sample
code, the Clarkson code all blindly remove a packet from the chain. There is
no check whether the chain is empty. How can this be, you ask, if the ring
has overflowed there must be at least one packet, right ? Wrong! If the
chain is empty and a string of all one's of let's say 6000 bytes is on the
network, the card will register an overflow, but the chain will be empty!
On one branch of a network at McMaster, this occurs about twice a day. It
also occurs infrequently on other parts of the network. 

I will post the changes if there is interest. The changes are to my code
but with a little work they can be placed in the Clarkson or other source.

Carl Beame
Beame@McMaster.CA

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 16:47:33 GMT
From:      dple@bii.UUCP (david levine)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PCIP




To anyone who has gotten PCIP to run,

I've been playing around with these sources for a bit and have had less
than success with them. (uucp'ed them from Harvard University)
The following are descriptions of the environments that I tried.

1 - NEC PowerMate 386/20 
    3Comm EtherLink II Ethernet Card rev. D

    Results: For the most part this was a bust. All applications died,
    the system had to be rebooted via soft and hard reboots. When 
    setting various debug flags within the code, it looks as if 
    it chokes when applications try to transmit. I tried running 
    the machine at 8Mhz (i286 emulation) only getting the same results.
    I also tried removing all other add on cards in order to insure
    that there wasn't a conflict of interrupt vectors or something
    as flakey as a bus arbitration problem. Again no go!

2 - NEC PowerMate 386/20
    Western Digital EtherCard PLUS Ethernet Card

    Results: Closer but no cigar. It seems as if we got much further.
    Programs weren't crashing but they were not doing much either.
    Ping as a client always timed out the remote server. Ping as
    a server never saw anything correctly. I did verify that data
    was transmitted (didn't look at the data though) Telnet exited
    giving a board setup error. Netwatch gave the most interesting
    results. It actually caught packets being sent across the net.
    However, the data that it printed out didn't look correct. I 
    payed close attention to the source and destination addresses;
    which did not match any of those on our network. It also printed
    out the same data for all packets. In general, I was glad to see it
    react.

3 - IBM AT Clone 
    Wester Digital EtherCard PLUS Ethernet Card

    Results: In general, same as when using the NEC. However, using Ping
    as a client caused the system to crash and could only be restarted
    by hard reboot.

4 - IBM 8088
    3Comm EhterLink II Ethernet Card rev. D

    Results: Same as 1. I think the driver isn't capable of handling
    this version of the card.

NOTE: I think it is also important to mention that the code was compiled
using the Microsoft C Compiler Version 4.0 and was ran under MSDOS
version 3.3. The assembler used was Microsoft MASM 4.0.

It would be greatly appreciated if anyone could help us out with this 
one. The reason why we are putting this much effort into getting
it to run,  is because we are considering porting TCP/IP to a 
propriatary platform and want to have a reliable set of sources to work
from. In addition, our operating system is as brain dead as DOS.
Please send all responses to me because our news feed isn't always 
reliable. I will forward  my findings at the request of anyone.


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

	
     ...         ...
    .    .     .    .	David Levine
    .     *   .     .	Software Engineer
     .      .      .
      .   .   .   .	Bruker Instruments Inc. USA
       . BRUKER .	Billerica, MA. 01821
      .   .   .  .
     .      .     .	
    .     *  .     .	dple@bii.bruker.com		Internet
     ...        ...     ...!{uunet,ulowell}!bii!dple	UUCP

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

    

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 17:15:26 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.misc,comp.protocols.pcnet,comp.protocols.tcp-ip
Subject:   A Map of Commercial Protocols Against the OSI Model

I would like some assistance in understanding where different
commercial protocols fit into the OSI seven layer model.  To
assist in this process, I have put together three tables (below)
that map the OSI model to each of the major commercial networking
environments.

What I propose is this:  please fill in the table for your area of
expertise whatever that may be.  As a favor to the network, I will
re-post updated versions of these tables with footnotes to
comp.protocols.misc.  Please send mail to me directly and do not
post to the net; I will incorporate all comments into the updated
tables.  Hopefully what will come out of this is a nice set of
reference tables that can be used to place different commercial
protocols into perspective - both in terms of the OSI model and
same-level protocols in other commercial environments.

Finally, if something similar to what I am doing here has already
been done as concisely somewhere else, please let me know.  No
need to redo work that has already been done well by someone else.


Instructions:

1) Please supply just the protocols/standards that are considered
"standard" for the commercial environment in question.  Do not
include a protocol in an environment just because it has been
ported there.  TCP/IP would *not* be considered a standard
protocol for a non-AIX IBM SNA environment, for example, although
it has certainly been ported to several SNA environments.

2) If a protocol does not neatly fit into the OSI model and in
fact spans more than one layer, please note this and give me a
rough idea of services provided at each layer.  I will make
provisions in the table to note that one protocol spans several
layers.


Notation:

1) Where something spans more than one layer, this is noted by
parens (e.g., NETBIOS(3), NETBIOS(4))

2) Footnotes are represented by brackets (e.g., NETBIOS [1]).

An item that both spans different layers and has
footnotes would look like this: NETBIOS(3) [1]

Thanks,
Will              (sun!portal!cup.portal.com!Will)


Tables:

OSI Layer    | IBM SNA     | Novell     | NETBIOS
------------------------------------------------------
Application  |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Presentation |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Session      |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Transport    |             |            | NETBIOS
             |             |            |
             |             |            |
------------------------------------------------------
Network      |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Data-Link    |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Physical     |             | Ethernet,  | Ethernet,
             |             | Arcnet     | Token Ring,
             |             |            | Arcnet
------------------------------------------------------



OSI Layer    | LAN Manager | UNIX       | DECnet
------------------------------------------------------
Application  |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Presentation |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Session      |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Transport    |             | TCP,       |
             |             | UDP        |
             |             |            |
------------------------------------------------------
Network      |             | IP         |
             |             |            |
             |             |            |
------------------------------------------------------
Data-Link    |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Physical     | Ethernet,   | Ethernet   | Ethernet
             | Token Ring  |            |
             |             |            |
------------------------------------------------------


OSI Layer    | Appletalk   | OSI        | Other
------------------------------------------------------
Application  |             | X.400,     |
             |             | X.500      |
             |             |            |
------------------------------------------------------
Presentation |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Session      |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Transport    |             |            | ISDN,
             |             |            | X.25
             |             |            |
------------------------------------------------------
Network      |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Data-Link    |             |            |
             |             |            |
             |             |            |
------------------------------------------------------
Physical     |             |            | FDDI
             |             |            |
             |             |            |
------------------------------------------------------

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 90 18:31:30 GMT
From:      stev@VAX.FTP.COM (Stev Knowles)
To:        comp.protocols.tcp-ip
Subject:   just when you thought it was safe . . . . .



would the appropiate people please fix this as soon as possible?

we have been getting SMTP connections from an increasing number of Internet 
hosts to the address 128.127.64.2 (128.127.0.0 is ftp's class B network.)

after much looking around in the DNS universe, and getting nowhere, we decided,
at some effort, to create the subnet and machine to find out what is going on.
from the mail that we recieved, we found who the addresse was, anf
from that we have found the following:


Query id 1281: 1 Questions, 1 Answers, 2 Name Servers, 3 Additional
 flags: <RESPONSE><CAN_RECURSE><DO_RECURSE>
MX (15) type Resource Record: sinet.ad.jp, class: Internet (1)
 Valid 0.91 hr (3264 sec):  MX Pref = 100, NAME: mtfuji.gw.u-tokyo.ac.jp
NS (2) type Resource Record: JP, class: Internet (1)
 Valid 143.91 hr (518063 sec):  DOMAIN NM: JP-GATE.WIDE.AD.JP
NS (2) type Resource Record: JP, class: Internet (1)
 Valid 143.91 hr (518063 sec):  DOMAIN NM: ACRUX.IS.S.U-TOKYO.AC.JP
Address (1) type Resource Record: mtfuji.gw.u-tokyo.ac.jp, class: Internet (1)
 Valid 0.91 hr (3264 sec):  Addr: 128.127.64.2
Address (1) type Resource Record: JP-GATE.WIDE.AD.JP, class: Internet (1)
 Valid 143.91 hr (518063 sec):  Addr: 133.4.1.1
Address (1) type Resource Record: ACRUX.IS.S.U-TOKYO.AC.JP, class: Internet (1)
 Valid 143.91 hr (518063 sec):  Addr: 133.11.7.185

from the above i have extracted the following useful information:

MX (15) type Resource Record: sinet.ad.jp, class: Internet (1)
 Valid 0.91 hr (3264 sec):  MX Pref = 100, NAME: mtfuji.gw.u-tokyo.ac.jp
Address (1) type Resource Record: mtfuji.gw.u-tokyo.ac.jp, class: Internet (1)
 Valid 0.91 hr (3264 sec):  Addr: 128.127.64.2




mail to the postmasters for the sites sending us mail has gone
unanswered for 2 days. now, to be honest, this isnt *really* screwing
me too much, it isnt my mail that is ending up on the wrong side of
the world. 

i am trying to get into contact with the people in japan. until then,
connectivity to sinet.ac.jp will be sent to a PC running our SMTP
package. we will be forwarding the mail messages on when it is
straightened out, but i dont have any idea how long this will take.


stev knowles
"suffering the slings and arrows of outragous fortune"

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 01:16:33 GMT
From:      escher@Apple.COM (Michael Crawford)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet


In article <506@nrcvax.NRC.COM> ihm@nrcvax.UUCP (Ian H. Merritt) writes:
>earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) says:
>>Am I the only Luddite out here that thinks that High Schools should not be
>>on the Internet?  Why not let High Schoolers continue to do what they should
 ...
>>(As for Jimmy/Janey Brainiac, let them take classes at their local colleges
>> and fall into the Black Hole via that route.)
>>
>>Donning the Asbestos (and sorry for the TCP/IP bandwidth waste),
>
>Hoping in turn that this message doesn't spark a flurry of responses
>(in which case, I'd wish to take it offline), I feel compelled to
>respond to this.
>
>I for one was using the ARPAnet, in what at the time was a legal gray
>area, since about 1975.  At that time, I was in high school, and had

Having been Jimmy Brainiac, I was very frustrated when I did go
take classes at my local college (Solano Community College), only
to find that I knew more than the instructors in many of my subjects,
that they had antiquated equipment (A DEC-10 with core memory,
shared with payroll and college administration, and your choice of
12-line dumb terminals or punch cards, all this in 1980).  Local
colleges are strapped for cash; SCC turned down an offer of a free
DECsystem 20 because they did not have $30,000 to build the building
to put it in.

I do have quite a bit of concern for network security and usage in
the face of high schoolers.  I think the biggest problem will be
hordes of "how do I set my terminal speed" etc. messages in the
Usenet news.  I think proper training of high-school administrators
(the teachers), who should pass on Usenet Etiquette to the students,
would take care of this (colleges should do this as well.  Make
the students take a brief class before having postnews work for
them).  Students could also be rude about running big FTP jobs in
the middle of the day.  Most of the security holes a high schooler
would try to exploit should be well known by now, and they would
not be likely to cover their tracks well if they did break in.
Worry more about how the KGB can just walk into public access
terminals in University libraries and log right in.

I remember when I was at SCC that I was pretty rude to the computer
center staff (sending anonymous love letters to GRIPE (they figured
it out who it was, and read them to the class!)), leaving infinite
loops that rang the buzzer (not a bell) on all the vt-52's, turning
the brightness all the way up so they would like damaged, and
turning them off (hey, what are the students doing to use up 40%
of the CPU time?).  Many of the pranks I pulled were out of
frustration from not having access to decent resources.  If I had
been on the Net I would have been in paradise.  (I am on the net
now, and I am in paradise, but also somewhat jaded.  Being on the
net then would have blown my mind.)

I have had some interaction with a high-schooler on the net: I got
mail from Puneet Pasrich, 6600bike%ucsbuxa@hub.ucsb.edu, a student
and Macintosh network administrator, asking about summer jobs at
Apple.  (I referred him to our summer internship program).  From
looking at his resume, and hearing what he has done with his network,
I am quite impressed.  I think there are many high schoolers who
should be on the net, who would benefit from it, and benefit us
all with their refreshing curiousity and enthusiasm.

-- 
Michael D. Crawford
Oddball Enterprises
606 Modesto Avenue	(Note address change; used to be 694 Nobel).
Santa Cruz, CA 95060
oddball!mike@ucscc.ucsc.edu

Consulting for Apple Computer Inc.
escher@apple.com

The opinions expressed here are solely my own.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 02:30:49 GMT
From:      marcog@Roma.ORC.Olivetti.Com (Marco Graziano)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

Can you please add this friend of mine from Italy to the mailing list?
Email address: 	oliveb!attila!spadoni  or
oliveb!attila!spadoni@atc.olivetti.com
Thanks.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 04:02:18 GMT
From:      amanda@mermaid.intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

In article <506@nrcvax.NRC.COM>, ihm@NRC.COM (Ian H. Merritt) writes:
> I for one was using the ARPAnet, in what at the time was a legal gray
> area, since about 1975.  At that time, I was in high school [...]

I'll second the claim that exposure to the Internet at an early age is
not necessarily a bad thing for either students or the Internet.  It was
in part being able to witness the ARPANET NCP/TCP changeover firsthand
(as well as discovering USENET in either late 1981 or early 1982) that
fired my interest in computer networks, eventually leading to my current
career.  Security is an issue, I admit, but I'd claim that it is already.
I imagine there are already a great number of bright young students using
the Internet and USENET in one form or another, and I think that the current
circumstances are even more dangerous than an "over the table" arrangement.

If the schools involved understand the responsibilities that go along with
the benefits, I don't see any reason to consider them guilty until proven
innocent...

--
Amanda Walker, InterCon Systems Corporation
--
"Y'know, you can't have, like, a light, without a dark to stick it in...
 You know what I'm sayin'?"     --Arlo Guthrie

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 04:23:08 GMT
From:      alex@netdev.comsys.COM (Alex Huppenthal)
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc,comp.unix.wizards
Subject:   Protocol development tools


  We want to experiment with development tools for communications protocols,
  specifically to develop, as a research project, an HDLC protocol,
  using some set of tools. 

  We are interested in any tools which facilitate the development
  of finite state machines, which emit 'C' as the final language.

  Commercial and public domain packages are of value here. If you have,
  or know of such tools, please post, or reply via E-mail, I'll summarize
  and post the findings.

  -Alex

-- 
     Alex            Internet:  alex@comsys.COM
     Huppenthal          UUCP:  {cs.utexas.edu!texbell}!netdev!alex 
     Communication Systems Research  6045 Buffridge Tr, Dallas, TX 75252  

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 04:46:36 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TELNET "front end"

In article <2613ecc0.2a57@polyslo.CalPoly.EDU> rnicovic@polyslo.CalPoly.EDU
(Ralph Nicovich) writes:
+---------------
| I have a computer that assumes it has a terminal directly connected
| to it, but instead it is connected to a Terminal server that speaks Telnet...
| My Idea is to dedicate a Unix Machine that will "front end" this
| application. Basically what I have in mind is that the User TELNETS
| to the Unix machine, which will automatically then TELNET to the [host]...
| Does anyone have some pointers to some code that will do this,
| or close to it that I can modify ?  I do not want to start
| from scratch with sockets etc.. I already thought of modifying
| the TELNET source, but would like to start with something a
| little closer to what I need.
+---------------

You actually might want to start with the "tn3270" source, which is itself
a hacked-up Telnet. It will show you the places where you can insert key
mapping types of hooks, etc. Just leave out the stuff about binary mode...

By the way, the idea of having an intermediate system to which you Telnet
and get automatically Telnetted out has been done before. A former client 
of mine had a no-password account named (say) "vmcms" on a certain Unix system.
Telnet-ing to it and logging in as "vmcms" exec'd a "tn3270" to the VM/CMS
system. (There are even ways to avoid having to log on the dummy intermediate
account.)

-Rob


-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 06:43:07 GMT
From:      kph@dustbin.cisco.com (Kevin Paul Herbert)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

I am one of the people that went to High School with Ian, and have had
first-hand experience with being a kid on the internet. I'm probably the
person that gave him the TIP numbers. :-)

At High School, we had a PDP-11/70 running RSTS. We loved to play various
pranks on the computer center, and did the whole thing of breaking into
systems and so forth. On the arpanet, however, we were just so swept
up by the culture, and by the fact that we could get free accounts at
MIT, that we didn't try to break into systems for fear of losing this
wonderful computer access. At our High School, we knew that getting to
use the PDP-11/70 was pretty much a given, so breaking the rules wasn't
so bad.

I think that if the internet is just treated as a given by High School
students, they'll cause lots of trouble. On the other hand, if it is
made clear that this is a very special thing, I think that it will capture
the curiosity of the really intelligent people, and really help the
industry.

The one thing that I worry about, though, is the "entertainment potential"
of the internet. Back when I was in High School, there weren't hundreds
of general-interest newsgroups to read. It would all seem to be a waste
if the really gifted kids couldn't use the computer because people were
busy reading rec.* groups.

Kevin

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 07:27:10 GMT
From:      oberman@rogue.llnl.gov (Oberman, Kevin)
To:        comp.protocols.tcp-ip
Subject:   Re: MX Records

In article <638650816.970000.LARSON@CRVAX.SRI.COM> LARSON@CRVAX.SRI.COM
(Alan Larson) writes:
.> Suprisingly, it is a technical error for the MXer of highest preference
.> to not be the host itself.  This would result in an empty MX list after
.> removing irrelevant RRs in the MXer of highest preference.  This is an
.> error condition, although it is noted that "974 points out that "extremely
.> persistent mail systems might want to try a delivery to REMOTE's address..."

Please note that many older RFCs (including 974) have been superceeded in part
by the host requirements RFCs (1122 and 1123). These give a remarkably clear
description of exactly how MX and A records should interact with mailers. It is
clearly NOT a technical error for the MXer of highest preference to be another
system.

If everyone would look at the aspects of this (including substantial increases
in the size of zone transfers), I think they might agree that the present
implementation (RFC1123) is the best way to go.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 09:06:58 GMT
From:      zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

>Am I the only Luddite out here that thinks that High Schools should not be
>on the Internet?

I also am unlucky about that, but I think we should not forbid
any interested people to use the internet, but we should design more secure
network software.

Joerg Hertzer
Computer Center University Stuttgart
West Germany
 

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 15:17:28 GMT
From:      MAB@CORNELLC.CIT.CORNELL.EDU (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: *** Summary: SLIP Header Compression

On 4 Apr 90 00:14:05 GMT you said:
> ...
>    First off, SLIP header compression is described in RFC 1044.
You mean RFC 1144.     - Mark

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 16:03:14 GMT
From:      MAINT@ASNTSU.asn.net
To:        comp.protocols.tcp-ip
Subject:   (none)

In-Reply To: att!cbnewsh!wcs@ucbvax.Berkeley.EDU
(Bill Stewart 201-949-0705 erebus.att.com!wcs)
Organization: Old-Timers rambling on about changes in society
Subject: Re: High Schools on the Internet

>]The Alabama Supercomputer Network has some sort of grant to connect several
>](5 or 6 in the first round) high schools to ASN.  ASN is a state-wide
>]T1-extended ethernet, supporting both TCP/IP and DECNET, and is connected
>
>My... and I thought it was a big deal when the high school I went to
>had a TTY-33 timeshared into a PDP-11 at the University of Delaware.
>This could be a good thing if you can find a way to get kids
>involved at a level they can handle intellectually, without forcing
>too much structure on them - playing around has a lot of value.

The grant being discussed here is not really intended for networking but
rather to promote interest in and understanding of supercomputing. The
network provides an inexpensive way for high schools to get access to the
CRAY here by dialing into a local gateway at one of the research universities
around the state. The pilot program included a supercomputing training
session for teachers with the objective of showing them how to work
supercomputing into their classes. The students and teacher then develop
a project requiring supercomputing capabilities. It is considered important
by the state education department to develop supercomputer interest at an
early age so that when they get to the state universities they can fully
utilize the supercomputer as part of their educational program. Anyway,
the point of this long winded dessertation is that there are legitimate
reasons for high schoolers to use internet even though that is not the
ultimate goal.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network

       +---------------------+
       |UNA           A&M    |
       |NFDC-------C--UAH    |
       |          / \        |
       |          | |     JSU|
       |   _____UAB-+----/   |
       | UA         |        |
       |            | ____AU |
       |          DSMD       |
       |        ASU | \      |
       |           /  TSU    |
       |         /           |
       |       /             |
       |     /               |
       |  _USA---------------+
       |/  \_|

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 16:23:30 GMT
From:      briand@infmx.UUCP (brian donat)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN NETWORK INFORMATION CENTER (NIC)


To summarize Mr. McDaniel's helpful posting, 

	the following is noted:

		NIC services are for registered DDN users and if
	    you should not fall into this category, you have no
	    access to the services and hence, no access to RFCs. 

	    So, whatever text or other references pointed you in
	    your persuit of net.knowledge to RFCs, the road ends
	    here if you're not a DDN user.   (Apparently)


I only have one question.   Are RFCs classified? 

BRIAND

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 16:50:49 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Gigabit throughput


Dave P. Wiltzius:

Hi.  

One point of reference is RFC 1077 on issues to be considered
in high-speed networking.

--jon

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 18:41:14 GMT
From:      martyne@batcomputer.tn.cornell.edu (Martyne Hallgren)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

Concerning the SuperQuest high schools, in addition to the actual set-up
of the network, I also presented a 1/2 day orientation to faculty and students
on networking.  This orientation included (in addition to the expected topics
of what does TCP/IP stand for???) a section which I called "Drivers Education
on the Electronic Highway". It covered some of the major points of Net 
Ethics/Net Etiquitte which are generally agreed upon ( what the net should 
be used for, its bad to turn worms loose etc).  The point of this talk being
that the Internet is a cooperative tool, where EVERYONE has a responsibility,
and that when the students (and teachers) used it, they became computer
professionals in the sense that they also had the same set of responsibilities
that we all have as Internet users.  

This section was well received by the teachers and I observed (at least) it
gave the students something to think about.  BUT this kind of orientation 
should be done not only for high schools but at the university level as well. 
I am continually amazed with the attitude that new ( and even not so new) users
are simply expected to know what are the "proper" things to do.  We dont' make 
this assumption with cars, why should we with computers????  (Obviously, this
can start a WHOLE new dialogue - let me go to a new topic).

Several people have commented on the impact that access to Arpanet had on 
them at an "early" age.  The Whole idea behind SUPERQUEST is to turn 
students on to scientific research, in this case specifically using 
supercomputing,  so that they look at it as a career
alternative and consider the PHD route as an.  There have 
been many, many, many papers/articles concerning the few number of PHD's
being produced from U.S. Universities today and the consequences. 
Two of the major consequences being the impact on industrial competitiveness
in the world marketplace and sheer numbers of faculty available to teach
in universities.  

The opportunities for this kind of motivation in education, the opportunities
for collaborative, multi-disciplinary science, the opportunities available 
to turn this science into products to compete with Japan and other Pacific
Basin countries and Europe - to the extent these ideas are bandied about 
in the press these days, they are almost cliches but it doesn't make them
any less valid.  It just makes it more apparent that the work being done
at the companies, campuses, regionals and backbone networks which make up
the Internet and keep it running it just that more important.  


martyne



************************************************************************
*  Martyne M. Hallgren       Internet:  martyne@tcgould.tn.cornell.edu *
*  Technical Advisor         Bitnet:    martyne@crnlthry               *
*  Cornell Theory Center     Phonenet:  607-255-9397                   *
*  265 Olin Hall                                                       *
*  Ithaca, NY 14853                                                    *
*                                                                      *
*" The mind, once expanded to the dimensions of larger ideas, never    *
*  returns to its original size."  -Oliver Wendell Holmes              *
************************************************************************

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 20:08:40 GMT
From:      WMP@STC10.CTD.ORNL.GOV (Mac Post, ORNL, Oak Ridge TN, USA)
To:        comp.protocols.tcp-ip
Subject:   ka9q's terminal emulation

I am using a copy of ka9q tcp-ip for the IBM/PC I got from SIMTEL20
archives.  After some fiddling with the setup parameters I got it to
work on our local net just fine.  I am wondering if some more
experienced users could help me with two problems.

One is that I can't seem to access remote hosts that lie beyond the
local gateway.  I presume that I have to set up some route or
netmask but I haven't stumbled upon the right combination yet.

Second, the version I have seems to emulate a fairly dumb terminal
when using telnet.  I there a way to get say vt102 emulation or
something that will allow full screen editing?  

Thanks
Mac Post
wmp@stc10.ctd.ornl.gov

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 20:40:21 GMT
From:      gvaudre@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   IETF and INTERNET-DRAFTS directories


The ietf and internet-drafts directories of the Internet Engineering
Task Force are being discontinued at NIC.DDN.MIL.  Due to continuing
connectivity problems, the information at NIC.DDN.MIL has been out of
date for over 1 month.

The ietf and internet-drafts directories will continue to be available
at NNSC.NSF.NET.  The NNSC.NSF.NET directories are current.  The ietf
directory contains:

	o a summary of the current ietf working groups
	o the charters and meeting minutes of the ietf working groups
	o upcoming meeting information, including the agenda, and rsvp
		form

The internet-drafts directory contains the current working drafts of
the IETF working groups.  These drafts are made available for public
comment prior to their submission to the Internet Activities Board for
publication as RFC's.  

We are in the process of finding additional locations for the
directories.  If you have any questions about this change, please
contact me at gvaudre@nri.reston.va.us.

Thanks for your patience

Greg Vaudreuil

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 90 21:04:02 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   auth 2.0 to be available on comp.sources.unix

Yes, folks, the auth package you've been waiting for is about to appear.
No longer do you have to settle for anonymous connections, forged mail,
or Berkeley's Internet interface. From the README:

  attachport - attach a server program to a TCP port
  authtcp - create a locally authenticated TCP connection to an Internet host
  authd - authentication server daemon
  authuser - remote authentication library
  
  This package provides two benefits. The first is a secure user-level
  implementation of RFC 931, the Authentication Server; unless TCP itself
  is compromised, it is impossible to forge mail or news between computers
  supporting RFC 931. The second is a single, modular interface to TCP.
  Programs written to work with authtcp and attachport don't even need to
  be recompiled to run under a more comprehensive network security system
  like Kerberos, as long the auth package is replaced.

And you get all this in an easy-to-install, slim package under 95K.

---Dan

P.S. Well, actually, Rich has only given a preliminary thumbs-up. And
you don't get mail authentication unless both ends support RFC 931 and a
mailer that understands it. But never fear, PUFF is coming...

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 00:26:59 GMT
From:      NIC@NIC.DDN.MIL (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   Improved connectivity for NIC.DDN.MIL

********************************************************************** 
DDN MGT Bulletin 72              DCA DDN Defense Communications System   
6 Apr 90                         Published by: DDN Network Info Center
                                     (NIC@NIC.DDN.MIL)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the NIC.DDN.MIL host [192.67.67.20]
using login="anonymous" and password="guest".  The pathname for
bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

                    NIC.DDN.MIL HOST ADDRESS CHANGE
                 AND ROOT DOMAIN SERVER ADDRESS CHANGE

In order for the NIC to provide better service, and because of the
phase-out of the ARPANET, the following changes have taken place and
are effective immediately (6 April 1990).

NIC.DDN.MIL
  The new address for host NIC.DDN.MIL is 192.67.67.20.

  The old ARPANET address for the NIC, 10.0.0.51, is no longer
  available, due to the phase-out of the ARPANET.

  The old MILNET address for the NIC, 26.0.0.73, will continue
  to be valid until 1 June 1990, after which service to this address
  will be discontinued.

ROOT DOMAIN SERVER
  The NIC's root domain server will run on a new host,
  NS.NIC.DDN.MIL at address 192.67.67.53.

  The old root server will continue to run on NIC.DDN.MIL
  until 1 June 1990.

New host tables and domain server files produced by the NIC will
reflect the new addresses.

Users should update host tables, domain server boot files, 
manuals, and documentation to reflect the new addresses.


The current list of root servers follows:

	   NS.NIC.DDN.MIL               192.67.67.53
	   A.ISI.EDU                    26.3.0.103
					128.9.0.107
	   AOS.BRL.MIL                  128.20.1.2
					192.5.25.82
	   C.NYSER.NET                  192.33.4.12
	   GUNTER-ADAM.AF.MIL           26.1.0.13
	   NS.NASA.GOV                  128.102.16.10
					192.52.195.10
	   TERP.UMD.EDU                 128.8.10.90
-------

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 00:36:24 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   time to get the ol' MIBs in...

Ladies and Gentlemen,
		    The "collecting of the MIBs" continues on, but not at the
pace that I envisioned. When I raised this issue several weeks ago it seemed
that there were many who added their voices that this was a GOOD THING. But,
quite honestly, I've only gotten about 10 mibs so far. Now I know that some
vendors may not have everything RFC1066 compliant yet. If so, that's certainly
understandable but please let me know that you're going to be coming forth
at some point with your extensions so I can count you among those who recognize
this is good for everyone. Right know everyone is scrambling around to get
all the mibs they need, and this same scenario gets repeated in untold companiesday after day. Were wasting time tracking down mibs instead of enhancing our
products. So if we put them all on a central site who wins? Well, the users
get a product that is truly "interoperable" right out of the box and they
feel good about buying into the SNMP management scheme. The vendors win 
because we DON'T waste time looking for XYZ mib.We spend it, instead, putting the
features into our products that the users want.
	So please let me know if we can expect your mib. Joyce Reynolds at ISI
has been gracious enough to have the archive down at ISI but doesn't want to
add to her workload too much. I've tried to help out by funneling them down to
her once a week. If you have a problem sending them via me let's talk about it.
Users can help out too by asking your favorite vendors if they've put their 
mibs into the repository.
	We can really only realize the potential of "standard management" if
we get away from proprietary thinking in the area of mib info. Please direct
comments, flames and, yes, even mibs to me.
		Thanks in advance,
				Chris VandenBerg
				(chris@salt.acc.com)
				805-963-9431

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 05:08:39 GMT
From:      LARSON@CRVAX.SRI.COM (Alan Larson)
To:        comp.protocols.tcp-ip
Subject:   Re: MX Records

My apologies for accidently resending a quoted article, originally by
Christopher JS Vance.  His article ended with the comment:

  >When I specify both A and MX records for a name, I mean what I say...

By my reading of the RFC, things should behave as you described wanting.
I sense agreemenmt here.

	Alan
-------

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 09:36:01 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with AIX "illegal protocols" ?


Tom,

This isn't an Ether type code but an IP Protocol type.  So
there isn't any confusion about a 91 byte length packet.

Don't confuse protocol type with packet type.

-c

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 10:13:32 GMT
From:      nick@spider.co.uk (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for AT&T V/386

> 
> In article <9840@netcom.UUCP> jbreeden@netcom.uucp (John Breeden) writes:
> >Does anyone know of an IP package for AT&T's SysV/386 R3.2.2 that supports 
> >ia SLIP interface?
> >

  dag@fmccva.franklin.com (Daniel A. Graifer) writes:

> We have Prime EXLs (386 Multibus II machines) running Prime's release of 
> ATT Sys V3.1.2.  On this, Prime supplied TCP/IP software originally from
> Spyder.  The implementation includes SLIP, X-25, uucp over other transport
> layers than uucico, etc.  It will act as a gateway, and support multiple
> ethernet controllers.  I saw that Spyder had a booth at the expo in DC last
> January, so they do sell their software direct.  Unfortunately, I do not 
> have a number for them.
> 

I'm afraid we don't.  Spider (that's I not Y!) only sells software in source
form to manufacturers, etc.  We sell network monitors direct in the USA and
a range of network boxes in Europe.

Hope this avoids any confusion.

Regards

Nick Felisiak				nick@spider.co.uk
Spider Systems Ltd			+44 31 554 9424

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 14:52:00 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Difinitive time server

In article <9004071424.AA15065@ucbvax.Berkeley.EDU> RUBIN%POLYGRAF@GRAF.POLY.EDU (David Rubin) writes:

   I am looking for a list of difinitive time servers on the Internet.
   I need to find the most accurate time possible.  Does anyone
   have a list of difinitive time servers?

You want to run NTP, the Network Time Protocol.  FTP a copy of
pub/ntp/clock.txt from louie.udel.edu.  The first few lines
follow:

========================================================================
= Information on NTP Time Servers and Radio Timecode Receivers         =
= Last updated 6 March 1989                                            =
========================================================================

General Information

This file is provided for information purposes only and represents the best
information available at the date posted above. It does not represent a
committment to provide connectivity or time service on the part of the
operators involved. Further information of a technical nature can be
obtained from the ntp@trantor.umd.edu list. To subscribe to this list,
contact ntp-request@trantor.umd.edu (Louie Mamakos).

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 20:09:03 GMT
From:      steve@wattres.UUCP (Steve Watt)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN NETWORK INFORMATION CENTER (NIC)

In article <3814@infmx.UUCP> briand@infmx.UUCP (brian donat) writes:
>		NIC services are for registered DDN users and if
>	    you should not fall into this category, you have no
>	    access to the services and hence, no access to RFCs. 
>
>	    So, whatever text or other references pointed you in
>	    your persuit of net.knowledge to RFCs, the road ends
>	    here if you're not a DDN user.   (Apparently)
>
>I only have one question.   Are RFCs classified? 

  If the RFCs were classified, they would be of no use to ANYBODY in the
real world.

  Also, the mail address (service@nic.ddn.mil) works for anybody...  I've
used it.

  It does mention several times that the ARPANet and MILNet are for companies
(or other organizations) that have some relationship with the US government, or
are educational institutions (I guess they have _some_ relationship with the
government, though... -- Something about educational funding... :)

  On a more general note, having re-read the article several times, I think
the above conclusions came from a paragraph that read something like:

| Military personnel or DoD contractors with proper authorization may obtain
| protocol-related documents such as circulars, directives, or memoranda from
| the Defense Technical Information Center (DTIC).
 [ DTIC's address removed ]

I think you missed the next line completely:

| Contractors and researchers without access to DTIC can obtain these
| documents from the NIC.

  Since the NIC also hands out internet numbers, it would not be very useful
for the general net.population if they only gave them out to ARPANet sites.
Handling mail forwarding for sites not connected (like all of the ones I use/
talk to) would not work well.

  Also:  Why do you think there's a section on "Publications Available from
the DDN Network Information Center (NIC)" if they weren't publicly available?
I STRONGLY recommend the DDN Protocol Handbook for anybody who's implementing
TCP on anything, since it is *THE* definitive spec.  (It's only $190.00, not
bad when you consider that it is 4 volumes, and well over 2000 pages.)

  Sorry if this sounded like a flame, but I've had several dealings with the
NIC, and they have been very helpful (if not particularly quick).

-- 
Steve Watt
...!claris!wattres!steve		wattres!steve@claris.com also works
If you torture your data long enough, it'll eventually confess.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 90 21:58:00 GMT
From:      0003786240@MCIMAIL.COM (VGCHAC)
To:        comp.protocols.tcp-ip
Subject:   ANSI Initiative on TCP/IP Protocol Suite



To: Internet Community Members
From: Vint Cerf, Chairman, Internet Activities Board (IAB)
Subject: Cooperative Work with ANSI X3S3.3

Below you will find an excerpt from the recently distributed
ANSI X3S3.3 meeting announcements prepared by Lyman Chapin,
the chairman of ANSI X3S3.3 and also a member of the IAB.

The Tucson meeting marks an important new stage in the
evolution of the Internet. As you will see, not only are
there joint meetings scheduled with the IETF IS-IS working
group, but on the agenda (see item 40, below) are proposals
to begin the process of entering the core Internet
Standards into the ANSI constellation of American National
Standards.

It would be hard to overemphasize the significance of this
opportunity to harness the joint interests of the Internet
Community and ANSI X3S3.3. As the Internet begins its journey
towards a multiprotocol environment encompassing OSI, TCP/IP
and other protocol suites, we will find our interests aligning
with those of others working in the data communications standards
fields: specifically, making multiprotocol systems work.

Along with Lyman, may I encourage you to participate in this
activity either through direct work with ANSI X3S3.3 or through
the appropriate IETF working groups?

Vint Cerf   
===================================================================
                EXCERPTS FROM THE ANSI X3S3.3
                  160th MEETING ANNOUNCEMENT



Please note the addition of an agenda item to discuss six new X3  
project proposals, covering the four core network and transport layer 
Internet protocols (TCP, IP, ICMP, and UDP), extensions to the intra- 
domain IS-IS protocol (DP 10589), and inter-domain routing.

This is the final agenda for the Tucson meeting of ANSI-accredited  
task group X3S3.3 (Network and Transport Layer Standards), which  
begins on April 16th.  The discussion of the new project proposals  
for the Internet standards will begin at 3:00 on Wednesday afternoon  
(April 18th).  ANSI task group meetings are always open to any  
interested parties. 


  
- Lyman Chapin
  Chairman, X3S3.3
  (lyman@merit.edu) 
- -------------------------------------------------------------------- 
   
 Accredited Standards Committee*                     X3S3.3/90-111 
 X3, INFORMATION PROCESSING SYSTEMS                  4 April, 1990 
  
                                                  A. Lyman Chapin 
                                       Data General Corp. MS D112 
                                              4400 Computer Drive 
                                                  Westborough, MA 
                                                              USA 
                                                  lyman@merit.edu 
  
  
                             Task Group X3S3.3 
                       Transport and Network Layers 
                     Meeting Announcement and Proposed 
                       Agenda for the 160th Meeting 
  
  
 DATE:       April 16-20, 1990 
  
 LOCATION:   Arizona Inn 
            2200 East Elm Street 
            Tucson, AZ 85719 
            800-421-1093 (direct line 602-325-1541) 
  
 TIME:       1:30 P.M. on Monday, April 16 
                  through 
            12:00 Noon. on Friday, April 20 
  
 FOR INFORMATION CONTACT:      Joel Snyder 
                              602-626-8680 
  
 NOTE:  A block of rooms has been reserved at the hotel under  
 the name "ANSI TG3 and TG7" at the rate of $80/single and $100/double;   
 these rates do not include 9.5% sales tax and 16% "gratuity", which  
 will be added to your bill, bringing it to $100.40/single and $125.50/double. 
 The hotel is 15 minutes from the Tucson airport.   
  
  
  
 The new proposed schedule, which is of course still subject to 
 modification during the opening plenary on Monday, has been revised to 
 accomodate an agenda item concerning project proposals for TCP, IP, 
 ICMP, UDP, and IS-IS extensions, and to include agenda item 25 
 (high-speed networking), which was erroneously omitted from the 
 original schedule. 
  
 Monday PM     Agenda items 1 through 7;  Network layer addressing 
              defect report [item 13];  IS functions [item 18]; 
              dynamic address assignment [item 37] 
  
 Tuesday       Joint meeting with IETF IS-IS working group to 
              discuss intra-domain IS-IS routing;  preparation of 
              DP 10589 ballot response and US comments [item 26]; 
              comments on proposed resolution of ISO 9542 defects 
              [item 20] 
  
 Wednesday AM  Network and Transport layer management [items 22 and 
              23];  High-speed networking [item 25] 
  
 Wednesday PM  Network and Transport layer security [items 38 and 
              39];  [at 3:00] new project proposals (90-85, -86, 
              -87, -88, and -104) 
  
 Thursday      Inter-domain routing [item 36];  Transport 
              conformance testing [item 16];  IP enhancements 
              [item 31] 
  
 Friday AM     Closing plenary;  review and approval of output 
              documents 
  
  
 The new project proposals contained in task group documents 90-85 
 through -88 cover the principal Network and Transport layer protocols 
 of the TCP/IP internet protocol suite, for which the Internet 
 Activities Board (IAB) and the Internet Engineering Task Force (IETF) 
 are responsible;  the proposal contained in 90-104 covers extensions 
 to the IS-IS intra-domain routing protocol (our existing project 756) 
 that make it possible to use that protocol to distribute intra-domain 
 routing information in a TCP/IP internet as well as an OSI internet. 
 These projects are intended to provide normalized ANSI-standard 
 reference points for the core internet protocols, which currently 
 enjoy the designation of Internet Standard under the auspices of the 
 Internet Activities Board, but are not well-positioned with respect to 
 the ANSI/IEEE formal standards taxonomy that locates almost all of the 
 other widely-used industry standards for communications and 
 networking.  The technical development of internet protocol 
 specifications remains where it belongs, with the IAB and the IETF; 
 the formal responsibility for bringing the results of that work under 
 a suitable standards umbrella will, if the proposed projects are 
 approved, fall to X3S3.3 and the ANSI standards process.  I have 
 discussed all of this with Vint Cerf, who chairs the Internet 
 Activities Board, and he has offered to join the X3S3.3 meeting for 
 the discussion of the new project proposals on Wednesday afternoon.  I 
 expect that Vint's participation will make it much easier to resolve 
 any questions that may arise concerning the responsibilities that will 
 be shared between X3S3.3 and the IAB/IETF if the project proposals are 
 approved. 
   
 This meeting will be held in joint venue with X3S3.7 and (on Tuesday) with the 
 IS-IS Working Group of the Internet Engineering Task Force.  Joint sessions 
 with X3S3.7 will be scheduled during the week if and as necessary.  A full-day 
 joint session with the IS-IS WG of the IETF is scheduled for Tuesday (the IS- 
 IS WG will also meet, independently, on Wednesday).  I have invited the IS-IS 
 WG members to participate as observers at any time during the X3S3.3 meeting. 

 ****************************************************************************** 
  
                               PROPOSED AGENDA 
  
  
 1.0    Opening remarks 
 2.0    Approval of agenda 
 3.0    Membership status 
 4.0    Approval of minutes of 159th meeting (90-78) 
 5.0    Arrangements for TG3 working group meetings and joint meetings with TG7 
 6.0    International liaison reports 
 7.0    USA liaison reports 
   7.1    X3S3 and task groups (Washington 3/20-21) 
   7.2    X3T5 and task groups (Phoenix 3/5-9) 
   7.3    SDNS 
   7.4    NIST OSI Implementors' Workshop (Gaithersburg 3/12-16) 
   7.5    IEEE 802 (Irvine CA 3/12-16) 
 8.0    Project 326:  OSI Network Layer 
 9.0    Project 332:  Connection-mode Transport Service and Protocol 
        (ISO 8072 and 8073) 
 10.0   Project 365:  Internetwork protocol (ISO 8473) 
 11.0   Project 462:  Connectionless Transport Protocol (ISO 8602) 
 12.0   Project 493:  Connectionless Transport Service Definition (ISO 
        8072/Add. 1) 
 13.0   Project 549:  Network Layer Addressing (ISO 8348/Add. 2) 
        Defect report (90-72) 
 14.0   Project 550:  Network Service Definition (ISO 8348) 
 15.0   Project 551:  Network Layer Architecture (ISO 8648) 
 16.0   Project 598:  Transport Protocol Conformance Testing 
        Test management protocol review (90-43);  Transport PICS [8073/DAD3] 
  
 17.0   Project 627:  IP Operation over the OSI Data Link Service (ISO 
        8473/Add.3) 
 18.0   Project 628:  Intermediate System Functions (ISO DP 10028.3) 
        Comments on outstanding issues from the second DP ballot (90-30) 
 19.0   Project 643:  Network Layer routing (ISO 9575) 
 20.0   Project 644:  ES-IS Routing Information Protocol for use with ISO 8473 
  
        (ISO 9542) 
        Comments on proposed resolution of defects (90-68) 
 21.0   Project 648:  ES-IS Routing Information Protocol for use with ISO 8208 
  
        (ISO DIS 10030) 
 22.0   Project 671:  Specification of Network Layer Management Information 
        Preparation of a revised working draft based on 89-263R and 90-27 
 23.0   Project 672:  Specification of Transport Layer Management Information 
  
        (90-53) 
 24.0   Project 674:  Transport Protocol Class 4 Operation over the 
  
        Connectionless Network Service 
 25.0   Project 753:  Protocols for Very High Speed Networking (90-45) 
 26.0   Project 756:  Intra-domain IS-IS Routing (ISO DP 10589) 
        Preparation of ballot response and US comments (90-48, -49) 
 27.0   Project PNS:  Protocol Combinations to Support the Network Service 
  
        (ISO 8880) 
 28.0   Project PID:  Protocol Identification in the Network Layer (ISO 9577) 
 29.0   Project NSI:  Support of the OSI Network Service by ISDN (ISO 9574) 
 30.0   Project TPE:  Enhancement of ISO 8073 (90-70) 
 31.0   Project IPE:  Enhancement of ISO 8473 (90-10) 
 32.0   Project TPF:  Formal Description of ISO 8073 in LOTOS (ISO 10023) 
 33.0   Project NTI:  Interworking between CO and CL End Systems (ISO 10172) 
 34.0   Project IPC:  Internetwork Protocol Conformance Testing 
 35.0   Project IPF:  Formal Description of ISO 8473 in ESTELLE 
 36.0   Project TER:  Inter-domain IS-IS Routing 
        Analysis of the ECMA (90-17, -51) and BRP (90-64, -71) proposals 
 37.0   Project DAA:  Dynamic Assignment of NSAP Addresses to End Systems 
        Decide whether or not the task group will pursue this project 
 38.0   Project NLS:  Network Layer Security (90-57) 
 39.0   Project TLS:  Transport Layer Security (90-58) 
*********************************************************************
 40.0   New project proposals (89-187, 90-85, -86, -87, -88, -104) 
*********************************************************************
 41.0   Other Business 
 42.0   Adjournment 
   

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 90 00:36:29 GMT
From:      ggw@wolves.uucp (Gregory G. Woodbury)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN NETWORK INFORMATION CENTER (NIC)

In article <3814@infmx.UUCP> briand@infmx.UUCP (brian donat) writes:
>To summarize Mr. McDaniel's helpful posting, 
>	the following is noted:
>		NIC services are for registered DDN users and if
>	    you should not fall into this category, you have no
>	    access to the services and hence, no access to RFCs. 
>
>	    So, whatever text or other references pointed you in
>	    your persuit of net.knowledge to RFCs, the road ends
>	    here if you're not a DDN user.   (Apparently)
>
>I only have one question.   Are RFCs classified? 

	The NIC.DDN.MIL supports "anonymous ftp" for access to the
RFC's and other documents.  Additionally, there are (I believe) RFC
archives on the uunet.uu.net site as well where there is anonymous
ftp and a 900 telephone number for uucp access.
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 90 06:04:55 GMT
From:      Mills@udel.edu
To:        comp.protocols.tcp-ip
Subject:   Re:  Difinitive time server

David,

See pub/ntp/clock.txt on louie.udel.edu. The adventure continues

Dave

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 90 09:47:38 GMT
From:      onoe@JP-GATE.WIDE.AD.JP (Atsushi Onoe)
To:        comp.protocols.tcp-ip
Subject:   Re: just when you thought it was safe . . . . .

> would the appropiate people please fix this as soon as possible?

I fixed my typo in database for address of mtfuji.gw.u-tokyo.ac.jp.
128.127.64.2 should be 128.167.64.2.  If your DNS still have the wrong
RR, would you please send me more informations?

> i am trying to get into contact with the people in japan. until then,
> connectivity to sinet.ac.jp will be sent to a PC running our SMTP
> package. we will be forwarding the mail messages on when it is
> straightened out, but i dont have any idea how long this will take.

Thank you very much for your efforts.

Atsushi Onoe

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 90 14:20:07 GMT
From:      steve@cise.nsf.gov (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

> I imagine there are already a great number of bright young students using
> the Internet and USENET in one form or another, and I think that the current
> circumstances are even more dangerous than an "over the table" arrangement.
> 
> If the schools involved understand the responsibilities that go along with
> the benefits, I don't see any reason to consider them guilty until proven
> innocent...

Amen.  -s

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 90 16:15:26 GMT
From:      paul@tenset.UUCP (Paul Andrews)
To:        comp.protocols.tcp-ip
Subject:   802.3 length field definition?

How much of an ethernet frame does the 802.3 length field include? In
particular, does it include the Frame Check Sequence octets?
-- 
------------------------------------------------------------------
| Paul Andrews             | Post: Tenset Technologies Limited,  |
| paul@tenset.uucp         |       Norfolk House,                |
| Phone: +44 223 328886    |       301 Histon Road,              |
| Fax:   +44 223 460929    |       Cambridge CB4 3NF, UK.        |
------------------------------------------------------------------

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 90 17:34:55 GMT
From:      ggw@wolves.uucp (Gregory G. Woodbury)
To:        comp.protocols.tcp-ip,alt.flame
Subject:   Re: High Schools on the Internet

In article <9004060906.AA00677@awssn3.rus.uni-stuttgart.de.> 
(Joerg Hertzer) writes:
>quoting someone else without attribution:
>>Am I the only Luddite out here that thinks that High Schools should not be
>>on the Internet?
>
>I also am unlucky about that, but I think we should not forbid
>any interested people to use the internet, but we should design more secure
>network software.

	I would think that anyone using this medium would react to the
name Luddite's the way that a Jewish person might react to the term NAZI!
The anti-technology implications of Luddite are just as bad as the other.

	Followup to /dev/null.  I only get alt.flame when cross-posted.
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 90 13:18:54 GMT
From:      aras@dr.uucp (Arne Asplem)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Is NFS for Motorola Delta-series available ?

Is there an implementation of NFS available for Motorola Delta series,
running System V Release 3 ?

If not is it possible to use implementations from other vendors ?

  -- Arne Asplem, aras%dr.uucp@nac.no

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 90 14:02:56 GMT
From:      nomann@rimfaxe.diku.dk (Ole Nomann Thomsen)
To:        comp.protocols.tcp-ip
Subject:   socket connection to printer (HELP wanted)

Hello, I need some help on this:

Configuration (probably more data than needed here):
Xenix 386, Excelan 3.5 Netsoftware
CS200 Connectionserver runnning SW/200-TCP-NCS/AT Vers. 3.2
One mannesman laserprinter connected to the former, 9600 Baud, Xon-Xoff.

I have a program, that sends to the printer, via the network. It works
by connecting a TCP stream socket to a port on a CS200 connection-server,
and sending the data throught that.

Problem:
If I just send the data, and then close down the connection, some data is
lost. (Probably the data, that was "in transit" when I closed). This
happends _Even_though_ the SIOCGLINGER-ioctl() call returns 0xFFFF, which 
is supposed to mean that the connection stays open until all data has been
acknowledged.

Temporary solution:
If I execute a sleep(60) (that is sleep one minute, not sleep from man60 :-)
before closing the socket, this prevents data-loss _except_ in large and com-
plicated printjobs. (I suppose sleep(120) might do the trick then)
				This is not satisfying, since it forces a one-minute break between
print-jobs, and still fails sometimes.

Appeal:
Can anybody help me on this ? I have read the FM quite a lot of times, and
made some experiments, I only post this as a last resort. If you email me the
answer, I shall post a summary. Thank you very much.
"Very good". - Johan Gambolsputty De Von AusFernSplendenSchlitterCrasCrenBonFriediggerDingleDangleDongleDungleBursteinVonKnackerThrasherAppelbangerHorowitzTicolensicGranderKnottySpelltinklerGrandlichGrumblemeyerSpelterwasserKurstlichHimble
EisenBahnWagenGutenabenBitteEineNurnburgerBratwurstleGespurtenMitzWeimachelUberHundsfutGumberaberSchonendankerKalbsFleischMittlerAuche Von Hautkopf of Ulm.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 90 16:14:31 GMT
From:      tom@tnosoes.UUCP (Tom Vijlbrief)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   how to route between two IP nets on the same physical ethernet

Problem:

How can I access a host on a different IP network which is on the
same physical ethernet as my own host ?

Own host: tnosoes (network izf-tno)
Other host: izfgate

I tried: route add host izfgate tnosoes 0

After which netstat -r shows:

Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
izfgate              tnosoes              UH       0      0          ie0
localhost            localhost            UH       6      895129     lo0
izf-tno              tnosoes              U        41     3646099    ie0

But I cannot ping izfgate !!!

What did I do wrong ?

Thanks in advance !

Tom
===============================================================================
Tom Vijlbrief
TNO Institute for Perception
P.O. Box 23				Phone: +31 34 63 562 11
3769 ZG  Soesterberg			E-mail: tnosoes!tom@mcvax.cwi.nl
The Netherlands				    or:	uunet!mcvax!tnosoes!tom
===============================================================================

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 90 16:22:00 GMT
From:      WHITESID@McMaster.CA (Fred Whiteside)
To:        comp.protocols.tcp-ip
Subject:   RE: re: MX Records

Christian Huitema <huitema@jerry.inria.fr> writes:

>  If the host has an A record, then the host is reachable directly via
>  the Internet. If one does not want to list that host as the MXer of
>  highest preference, it is probably that one does not want to receive
>  mail directly on that system, but rather feed the mail through some
>  "central" server. Indeed, there might be some good reasons for that,
>  like not wanting to receive mail directly on a PC.. BUT!!

        Invalid assumption. I have several machines which are directly
on the network that _cannot_ process SMTP (the two that spring to mind
are VMS vaxen with Bridge communications IVECS boards. These things
look like DMF's to the Vax and process the TCP Telnet on the board).
These machines want mail, but they *must* have it delivered via a
decnet channel. The MX forwarders for these machines understand this
so it all works.

>  Rather than prohibiting mailers to look at A records, Philip should
>  rather consider cleaning his own house, and not advertise the
>  addresses of PC or work stations as valid mail addresses!

        I can envision a scenario where I have seen an ftp connection
from some machine to my site and I want to send mail to
root@thatmachine for some logical reason. I reverse-lookup the IP
address and send mail to POSTMASTER@TheLooked-upAddress. The machine
may be a PC which won't handle inbound TCP connections and thus I
should have an MX record for the machine that points to a mailer that
Knows What To Do.

        The MX records are there for a good reason. Let's use them
properly. A records are host addresses. MX records are where you want
the mail delivered. It's quite simple.

-Fred Whiteside
 McMaster PostMaster, DNS Maintainer and Guy Who Worries About Such Things

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 90 17:24:19 GMT
From:      solensky@interlan.interlan.COM (Frank Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN NETWORK INFORMATION CENTER (NIC)

>I STRONGLY recommend the DDN Protocol Handbook for anybody who's implementing
>TCP on anything, since it is *THE* definitive spec.

... plus RFC 1122 and 1123 -- the Host Requirements RFCs (Communications Layer
and Applications & Support, respectively).  These contain explicit directions
on many of the points that the Protocol Handbook RFCs either leave open to
interpretation, misstate, etc.  Getting this before claiming interconnectivity
will save yourself a tremendous amount of aggrivation later on.

			Frank Solensky
			Racal InterLan

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 90 20:14:37 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Network Software Repositories


	I'm putting together a list of network software repositories. If
your site provides anonymous FTP access to network-related sources, please
send me mail with a host name and either a list of the software and a brief
description, or a pointer to an index file that contains it.
	We're looking for TCP/IP sources and applications that help manage
TCP/IP internets and not, for example, window managers, shells, etc. The
kinds of things I'm talking about: gated, KA9Q, BSD net sources, SNMP sources,
etc. You can help me by just replying to this posting, or using the subject
"Network Software Repositories".
	Example mail:

---
	Subject: Re: Network Software Repositories

	lancaster.andrew.cmu.edu, SNMP, an SNMP implementation
---

	Please do NOT send me information about products. Only public
domain or freely redistributable copyrighted network software will be
included.
	If you know of alternate (backup) sites for the same distribution,
please include those host names as well.

	Thanks in advance to all who can help!

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 00:45:51 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: DDN NETWORK INFORMATION CENTER (NIC)


brian donat:

RFCs are not classified.  The intent is to make the information publicly
available.

I would like to hear about any case of someone being denied access to an
RFC as a matter of distribution policy.

--jon.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 13:21:00 GMT
From:      mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL")
To:        comp.protocols.tcp-ip
Subject:   RE:  DDN NETWORK INFORMATION CENTER

Andrews AFB

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

                                        Date:     10-Apr-1990 08:58am EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )


Subject: RE:  DDN NETWORK INFORMATION CENTER

"FLAME ON"


The Requests for Comments (RFCs) listed by the DDN Network 
Information Center are not repeat are not classified.

Also, for all the users who asked that question, instead of 
addressing this question over the TCP-IP mailer listing, why not
call the 1-800-235-3155 DDN NIC and ask them, they don't bite, 
growl, or grumble when you call and ask for assistance.  They were 
established for user assistance, also they interface daily with
INTERNET users and have a listing for a majority of the INTERNET 
DOMAINS.  So, save your money on sending E-Mail and spend a "dime" 
and call the DDN NIC and get the latest information, if you have 
any further questions.

"You lead a horse to water, but you can't make him drink."


The same goes for posting information, someone always focuses on a 
small issue, when the answer is already available, all it takes is
initiative. 

That's what you get for trying to be helpful.


RODNEY A. MCDANIEL, DAFC
Information Systems Manager
Andrews AFB MD
Email Adress:  MCDANIEL@HQAFSC-VAX.AF.MIL

"FLAME OFF"

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 15:09:42 GMT
From:      riku@field.fi (Riku Kalinen / Systems)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Is NFS for Motorola Delta-series available ?

In article <638@dr.uucp> aras@dr.uucp (Arne Asplem) writes:
>Is there an implementation of NFS available for Motorola Delta series,
>running System V Release 3 ?

Yap. NFS is supported in Network Services Extension 3.6, which (suprise!)
needs System V release 3 version 6 (the most recent Moto version).

Disclaimer: I work for Moto distributor.


-- 
Riku "the bit" Kalinen                               E-Mail : riku@field.FI
FAE/Systems, Field Oy.                               Telex  : 122022 field sf
                                                     Phone  : +358 0 757 1011
"Welcome to the party, pal!" (From movie Die Hard)   G3 Fax : +358 0 798 853

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 16:50:31 GMT
From:      buzzard@eng.umd.edu (Sean Barrett)
To:        comp.protocols.tcp-ip,alt.flame
Subject:   Re: High Schools on the Internet

In article <1990Apr8.173455.7844@wolves.uucp> ggw@wolves.UUCP (Gregory G. Woodbury) writes:
>	Followup to /dev/null.  I only get alt.flame when cross-posted.
>Gregory G. Woodbury
Hey dud, eat me.  Don't waste your time posting to alt.flame if you're not
going to read it.

And fuck your followup-to.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 17:14:57 GMT
From:      DYOUNG@A.ISI.EDU (C. David Young)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q's terminal emulation

If you add "route add default ec0 [xxx.xxx.xxx.xxx]" to your
autoexec.net, where xxx.xxx.xxx.xxx is your gateway address, ka9q will
send packets for which it does not have a specific route to this ip
address.

I too am interested in VT102 capability for ka9q.  Please let me know if
you find anything out.

David
-------

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 17:54:01 GMT
From:      tom@dvnspc1.Dev.Unisys.COM (Tom Albrecht)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.dcom.lans,comp.sources.wanted
Subject:   Public domain SPX?


I understand there is a public version of SPX(XNS) somewhere on Usenet.
Is this information correct?  Could someone direct me to the server where
such a thing might be located?

Thanks.

-- 
Tom Albrecht

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 19:13:20 GMT
From:      kdq@demott.COM (Kevin D. Quitt)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Is NFS for Motorola Delta-series available ?


Motorola Part #M68NNTBVNE, list price $420.  Available from Motorola or
any dealer (like us). 

The other choice is to upgrade to 3.6, which includes NFS. (M6836TBV68,
$1200, or $1600 with manuals).

kdq
-- 

 _
Kevin D. Quitt                          Manager, Software Development
DeMott Electronics Co.                  VOICE (818) 988-4975
14707 Keswick St.                       FAX   (818) 997-1190
Van Nuys, CA  91405-1266                MODEM (818) 997-4496 Telebit PEP last
34 12 N  118 27 W                       srhqla!demott!kdq   kdq@demott.com

 "Next time, Jack, write a God-damned memo!" - Jack Ryan - Hunt for Red October

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 21:27:16 GMT
From:      craigs@cognos.UUCP (Craig Statchuk)
To:        comp.os.os2,comp.protocols.tcp-ip
Subject:   TCP/IP support under OS/2



"Is there a package that provides good TCP/IP support under OS/2?"

Our basic requirement is for an OSI Transport level interface (preferably
BSD style Sockets) that works when linked to a OS/2 protected mode
application.

The software we are developing uses a client/server model where the
OS/2 applications will run as a client or a server.  Servers will also run
on mainframes under UNIX, VMS, etc.


      +------------------+
      |  OS/2 Protected  |
      |   APPLICATION    |  
      +------------------+ <----+
      | Session Interface|      |   The Missing Link is here.  We do not
      +------------------+      +-- have a product that provides
      | TCP/IP Drivers   |      |   Program-to-Program TCP/IP connections
      +------------------+ <----+   from OS/2
             |
             |/|  TCP/IP
               |
    +----------------------+
    |     Server Task      |         
    |(OS/2,UNIX,VMS,..etc) |
    +----------------------+


Can anyone share their expertise in this area?

-- 
Craig Statchuk           P.O. Box 9707        uunet!mitel!sce!cognos!craigs
Cognos Incorporated      3755 Riverside Dr.   craigs%cognos.uucp@uunet.uu.net
HUMAN: (613) 738-1440    Ottawa, Ontario
FAX:   (613) 738-0002    CANADA  K1G 3Z4

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 90 22:45:47 GMT
From:      briand@infmx.UUCP (brian donat)
To:        comp.protocols.tcp-ip
Subject:   RFCs are not Classified


Thanks to all of you who became concerned over my access 
difficulties to RFCs. 

Now, to head off any further concerns, let me tell you
that a recent posting describing NIC's address changes and
a call to SRI's 800 number have fully straightened me out
a full couple of days past.  Having no prior knowledge of 
the address change at NIC had frustrated my attempts to get 
RFCs using the old 'ARPA' mailing address for the SERVICE 
and this lead me to further confusion by misinterpreting 
passages in Mr. McDaniel's recent posting.  

Using the new Address at MIL works fine. 

In the mean time, my confusion has afforded me with much
more helpful information still, from those who became
concerned about my last posting.   The net is indeed a 
very knowledgable (and hospitable) place.

Again, thanks. 

This is about as orderly a release as I can do for now
from my end.  Should anybody open this socket again, direct 
them back to the recent cascade of articles which relate my 
recent confussion. 

--briand

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 02:51:21 GMT
From:      pja@ralph.Lafayette.LA.US (Pete Alleman)
To:        comp.unix.i386,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Ethernet Cards for PC and Unix

I'm looking for an Ethernet board for an IBM-PC compatible
running Interactive 386/ix.  Which is the best board for high
performance (with Unix driver availabe)?  My only experience is
with the WD 8003E.  I would assume that there are better cards.

Is anyone running Western Digital's 16 bit Ethernet card?
Interactive does not have a driver for this board, but Western
Digital has a driver on their bbs.  Anyone tried it?

I've been trying to get a WD 8003S Starlan card working with my
employers network.  It drops most of the packets.  The thruput
is so low that a 300 baud serial line is faster.  All the other
equipment on the network is from Hewlett Packard.  Is there a known
problem with mixing Western Digital and Hewlett Packard?

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 08:40:23 GMT
From:      zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

In an E-Mail on this list

Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)

wrote:

>In article <9004060906.AA00677@awssn3.rus.uni-stuttgart.de.>
>(Joerg Hertzer) writes:
>>quoting someone else without attribution:
>>>Am I the only Luddite out here that thinks that High Schools should not be
>>>on the Internet?
.
.
.
>	I would think that anyone using this medium would react to the
>name Luddite's the way that a Jewish person might react to the term NAZI!
>The anti-technology implications of Luddite are just as bad as the other.

Two remarks:

1. I quoted an E-Mail of
 	Greg Earle
	Sun Microsystems, Inc. - JPL on-site Software Support
	earle@poseur.JPL.NASA.GOV	(direct)
	earle@Sun.COM			(indirect)
   and wrote that in my E-Mail.

2. English is a foreign language to me. I have newer seen the word 'Luddite'
   before and cannot find it in my dictionaries.

Joerg Hertzer
Computer Center University Stuttgart
West Germany
zrfp0128@awssn3.rus.uni-stuttgart.de

Phone:
++ 49-0711-685-5803

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 08:51:20 GMT
From:      zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet


Just now I sent an E-Mail with:
(about an elder one from me)

.
.
.
   I quoted an E-Mail of
 	Greg Earle
	Sun Microsystems, Inc. - JPL on-site Software Support
	earle@poseur.JPL.NASA.GOV	(direct)
	earle@Sun.COM			(indirect)
   and wrote that in my E-Mail.
.
.
.
Now I found two copies of that elder E-Mail on my disks.
One with and the other without that attribution.
Seems I sent the wrong one - Sorry!

Joerg Hertzer

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 14:49:13 GMT
From:      Mills@udel.edu
To:        comp.protocols.tcp-ip
Subject:   Re:  NTP (was Re: Difinitive time server)

Ed,

I can't help you a lot with the platform mechanics, but I do observe
the dispersion on the 4/390 is outta sight. The precision parameter
should not affect this, but the tickadj might; however, I would suspect
the culprit is lost clock interrupts. Others on this list might be
able to give more definitive anecdotal evidence. Ahem.

Dave

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 15:22:13 GMT
From:      rhoward@msd.gatech.edu (Robert L. Howard)
To:        comp.protocols.misc,comp.protocols.nfs,comp.protocols.tcp-ip,comp.unix.questions
Subject:   FAX on UNIX / TCP/IP Networks with PC's

Has anyone out there used PC-NFS with a FAX modem that is hooked up to
a UNIX host?  Is this even possible?

What I'd like to be able to do is have PC users on the network be able
to send a file (PostScript, Word Perfect, ASCII, etc.) over the FAX
modem that is remotely mounted to one of the LPT ports.  I think this
would require some FAX sotware for the PC but I think that some of this
is already available.  Another option would be to have some of the 
<whatever>-to-FAX filters on the UNIX host.  The biggest problem I see 
is how to handle dialing the phone number; that seems like an interactive
kind of task.  (This brings to mind the more general problem of using a 
modem remotely, without logging on the host and using tip.   I'll leave
that to a separate discussion.)

Anyone got any pointers?

Robert
(I hope I didn't over cross-post this; remove groups as needed)
--
Robert L. Howard  (GTRI/STL/MSD)             (404) 528-7165
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!msd!rhoward
Internet: rhoward@msd.gatech.edu

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 15:40:34 GMT
From:      pte900@csc.anu.oz (Peter Elford)
To:        comp.protocols.tcp-ip
Subject:   Re: X window interface to White Pages

In article <29453.639763981@cheetah.nyser.net>, mrose@CHEETAH.NYSER.NET (Marshall Rose) writes:
> Hi.  Some time ago I sent a note to the list introducing the
> NYSERNet/PSI White Pages Pilot Project (a large, distributed white pages
> service spanning multiple administrations).  I am pleased to announce
> that we have added a new service for anonymous use: X window access to
> the White Pages.
> 
> The "xwp" application displays the portions of the white pages you find
> "interesting", allowing you to both search the white pages and browse:
> by clicking on an entry, you can find out about it's children or about
> the entry itself.

And it works well.

> 2. You will be asked if X window access is desired.  If so, you enter
> the name of your X display.  This should be something like
> IP-address:0.0, e.g.,
> 
> 	192.33.44.20:0.0

Sometimes you don't get the prompt for your display IP address and get 
dropped into the old line-mode wp server. Why is it so ?

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax: +61 6 247 3425
c/o, Computer Services Centre,			post: PO Box 4
Australian National University			      Canberra 2601
Canberra, AUSTRALIA		

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 17:18:11 GMT
From:      craigs@cognos.UUCP (Craig Statchuk)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.pcnet
Subject:   Sources for NDIS drivers

Does anyone know where I can obtain NDIS drivers for 3Com ethernet
cards (3C501, 3C503, 3C505 AND 3C523)?  

Some other naive questions: 

  1: Do such drivers even exist?

  2: Is this a good way to achieve hardware independence?

We intend to use the drivers on both ISA and MCA machines running
OS/2 SE and MS-DOS (with WINDOWS in some cases).

Thanks in advance for any help.  I will summarize responses for the net...




-- 
Craig Statchuk           P.O. Box 9707        uunet!mitel!sce!cognos!craigs
Cognos Incorporated      3755 Riverside Dr.   craigs%cognos.uucp@uunet.uu.net
HUMAN: (613) 738-1440    Ottawa, Ontario
FAX:   (613) 738-0002    CANADA  K1G 3Z4

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 17:36:00 GMT
From:      MTSJLM@GSUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   BITNET mail follows

Date: 11 April 1990, 13:30:24 EDT
From: MTSJLM   at GSUVM1
To:   TCP-IP at SRI-NIC.ARPA

    Does anyone out there know of a Name Server that will run on SCO XENIX/UNIX
or a SUN SPARC Workstation running SUNOS?  We are implementing a Class B
Ethernet connecting SUN Workstations to a Silicon Graphics Supermini Computer
and to an IBM Token Ring through a Wollongong Gateway.
    Please reply directly to me (MTSJLM@GSUVM1.BITNET).

Thanks in Advance,

Jorge Morales
Systems Communications Analyst
Well's Computer Center
Georgia State University

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 21:16:00 GMT
From:      pete@CS.UMD.EDU (Pete Cottrell)
To:        comp.protocols.tcp-ip
Subject:   inappropriate posting


	Please excuse my posting this here - I realize that it doesn't
have anything to do with TCP/IP. However, the volume of messages we are 
receiving warrants a short response, I believe.
	As you have no doubt seen, an extremely rude and totally inappropriate
message was posted by mojo!buzzard@mimsy.umd.edu to this list. An apology
was posted a short time later. Many people have sent letters complaining
about the initial posting to postmaster@mimsy.umd.edu.
	The author did not send this mail from mimsy.umd.edu or any other
U of Md computer science department machines. Instead, it was posted from
the 'mojo' machine in another department. Mimsy's only part in this is that
it is the news feed for mojo. We believe that the confusing address may have
been generated in the transition from USENET newsgroup to Internet mailing
list.
	All complaints have been forwarded to the administrators of mojo
and they are aware of the problem and are taking the actions they feel
are appropriate. Mail bringing the posting to their attention is no longer
necessary. Still, if you want to communicate your outrage to them, then 
please send mail to mojo.eng.umd.edu and not mimsy.
	We are embarrassed by the posting and hope that if doesn't reflect
on the university as a whole. We hope that we can put this behind us and
that the high signal-to-noise ratio will continue on this valuable list.
Thank you for your understanding.

	Pete Cottrell
	Computer Science Department
	University of Maryland

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 21:55:17 GMT
From:      merlin@csvax.seas.smu.edu (David Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcasting Adreess and Subnets

In article <362@jove.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul)
writes:
>Since I wrote RFC922, I've had a change of heart; I agree that multi-
>subnet broadcasts are a bad idea.  I've heard from some people that
>RFC1009 can be read to require their support, and also to require that
>if supported that one can configure them to be blocked; my reading of
>RFC1009 is that gateways are not required to support them.  At any rate,
>this is clearly an issue for the Router Requirements Working Group, and
>I hope that they rectify my error.

I'm working on a printer accounting program that runs throughout
our (subnetted) campus network.  It uses a client-server
architecture.  There are multiple, redundant servers.  I wanted
our system to be able to find the servers by broadcast, but our
cisco router doesn't forward them.  

That's at least one application for which multi-subnet broadcast
was the correct solution.  I don't think Jeff made a mistake
originally.  While any broadcast should be used sparingly, totally
prohibiting multi-subnet broadcasts needlessly deprives us of a
clean solution to my class of problem.

David Hayes	School of Engineering	Southern Methodist University
merlin@smu.edu	uunet!smu!merlin
"Here's a test to see if your job here on Earth is finished:  If you're
still here, it isn't."  -- Richard Bach, _Illusions_

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 90 23:48:57 GMT
From:      andre@inducom.uucp (Andre Somberg)
To:        comp.org.decus,comp.sys.dec,comp.dcom.lans,biz.dec,comp.protocols.tcp-ip
Subject:   DECnet "undocumented features" ???

Can anyone tell me what changes DEC has made to the DECnet protocol since the
manuals have been released? In other words, what features (bugs?) has DECnet
that are not documented?
Thanks for helping me!!

PS Please mail us the answer or post it to protocols.tcp-ip!

-- 
Andre Somberg, Inducom Systems B.V., P.O. Box 627, 5340 AP  Oss, Netherlands
FAX +31-4120-22640
andre@inducom.uucp               ..!mcsun!hp4nl!inducom!andre
-- Listen carefully. I will say this only once. ('Allo 'Allo) --

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 90 01:11:57 GMT
From:      carlitz@unix.cis.pitt.edu (Robert D. Carlitz)
To:        comp.protocols.tcp-ip
Subject:   networks for grades K-12

Recent postings to this newsgroup have discussed the connection of high
schools to the Internet.  People interested in this topic may be
interested in the KIDSNET mailing list.  This mailing list was
established a little under a year ago.  It is dedicated to the idea of
creating an international network for the use of children and their
teachers.  The time is probably right for this activity.  The necessary
equipment is affordable and political barriers to this type of activty
are dropping world-wide.  On purely commercial grounds this represents a
vast untapped market.  One can enumerate many educational advantages
(for both children and teachers) of a networked school environment.  As
access to information becomes a more and more central element in
managing the world's activities, it makes sense to provide children with
the tools essential for the job.  Computer networks offer the potential
to share information on a worldwide basis, to link different societies
and disparate cultural groups within a given society.  They place the
able-bodied and the physically handicapped in a mutually supportive
relationship.  At least that's how it looks to me.  If you would like to
subscribe to the KIDSNET mailing list, send your subscription request to
either
	joinkids@vms.cis.pitt.edu
or
	kidsnet-request@vms.cis.pitt.edu
BITNET fans may access vms.cis.pitt.edu as PITTVMS.BITNET.  I look
forward to hearing from those readers of comp.protocols.tcp-ip who would
like to help develop this new venture.

Bob Carlitz

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 90 01:30:56 GMT
From:      dlucy@tropez.UUCP (Doug Lucy)
To:        comp.protocols.tcp-ip,comp.unix.i386,comp.unix.xenix,comp.sys.ibm.pc
Subject:   Unix 386 3.2, DOS, & TCP/IP

We're getting ready to develop some s/w for a client using a mix
of PC's, Novell Netware on Lattisnet, and a NCR Tower running Unix
r2 with TCP/IP.

To simulate this enviroment (hah) we're putting the programmers on PC's
connected via thin ethernet to a 386 running *nix 386. Now the question
comes as to which TCP/IP and which TELNET and which RLOGIN (I am using
this terms right?)

Anyways, here's the real questions:

	For the PC, we'll be using DOS 3.3 and/or Windows/286
	with Western Digital WD8003E cards. What software should be
	used? (It'd be nice if it's PD)

	For the Unix box, we've got an idle (hah) 386-25 with
	SCO Xenix 2.3.2. We can also use AT&T Unix V/386 3.2, if
	thats better. Again with the WD8003E and again which 
	software package should we buy? (There MUST be a PD TCP/IP
	for this OS somewhere)

	For communicating (at the application level) between
	host and remote, what libraries exist for sending messages?
	Or should a RFS pipe/file message system be used? Is this
	where STREAMS comes in?

	Is the WD8003E card going to drag the 386 way down? Can
	the card even be used in the server?

Thanks much.
-- 
   "It's such a fine line between stupid..."    | Doug Lucy  703.820.3922
   "...and stupid."                             | DC Pro, Falls Church, VA
   "Yeah, stupid."                              | uunet!tropez!dlucy

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 90 10:05:50 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   RE:  DDN NETWORK INFORMATION CENTER

Rodney,

"You can lead a horse to water, but you can't make him drink" you said,
but you can feed him salt!

dennis

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 90 18:54:34 GMT
From:      paul@cscnj.UUCP (Paul Moody)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   B1 secure TCP/IP

Hello netland.

I have been asked to track down info on a DOD B1 secure implementation
of TCP/IP. The requestor believes that a company called ADAMAX(sp?)
produces such a beast but has not been able to track them down.

If anyone out there knows of any implementation or if the people
from ADAMAX read this news group, please help me out.

Thanks in advance
Paul
-- 
Paul Moody			UUCP: rutgers!cscnj!paul 
Computer Sciences Corporation
# the opinions expressed are entirely imaginary			#

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 90 19:25:52 GMT
From:      lmg@hpindwa.HP.COM (Lisa Gullicksen)
To:        comp.protocols.tcp-ip
Subject:   Is there SNMP Certification Testing?


Is there any certification testing supported by the IAB or other Internet
body for SNMP agents and managers?  From what I've heard thus far it
sounds like most vendors "certify" their SNMP implementations through
selected interoperability testing, trips to INTEROP, or a special     
Connectathon sponsored by numerous companies.

Please mail responses to: lmg@hpindzl.hp.com.

Lisa Gullicksen
Hewlett-Packard Co.
Cupertino, CA

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 90 19:28:56 GMT
From:      bill@fedeva.UUCP (Bill Daniels)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   SNMP agent for DEC Ultrix??

Is anyone familiar with using SNMP to manage a DEC Ultrix machine,
specifically the DECsystems and DECstations running Ultrix 3.1[C].  We
have accumulated some SNMP manageable devices on our small TCP-IP
ethernet and would also like to be able to determine that our host nodes
are alive/not-alive.  How might I accomplish this?

-- 
bill daniels
federal express, memphis, tn
{hplabs!csun,mit-eddie!premise}!fedeva!bill

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 00:58:22 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcasting Adreess and Subnets

In article <16240@smunews.UUCP> merlin@csvax.seas.smu.edu (David Hayes) writes:
>In article <362@jove.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul)
>writes:
>>Since I wrote RFC922, I've had a change of heart; I agree that multi-
>>subnet broadcasts are a bad idea.
>
>I'm working on a printer accounting program that runs throughout
>our (subnetted) campus network.  It uses a client-server
>architecture.  There are multiple, redundant servers.  I wanted
>our system to be able to find the servers by broadcast [...]

Well, I'm still against multi-subnet broadcasts; you should lean
on your vendors to support the Internet Group Multicast Protocol (RFC1112).

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 03:25:48 GMT
From:      ggw@wolves.uucp (Gregory G. Woodbury)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

In article <9004110840.AA02224@awssn3.rus.uni-stuttgart.de.> 
zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer) writes:
>In an E-Mail on this list
>
>Gregory G. Woodbury
>wrote:
>
>>In article <9004060906.AA00677@awssn3.rus.uni-stuttgart.de.>
>>(Joerg Hertzer) writes:
>>>quoting someone else without attribution:
>Two remarks:
>1. I quoted an E-Mail of
> 	Greg Earle
>	earle@poseur.JPL.NASA.GOV	(direct)
>	earle@Sun.COM			(indirect)
>   and wrote that in my E-Mail.

	Yes, my mention of without attribution referred to the way that
the included text was marked.  It was my fault for not properly preserving
the attributions.  The response is to Greg Earles posting, not yours.

>2. English is a foreign language to me. I have newer seen the word 'Luddite'
>   before and cannot find it in my dictionaries.
>Joerg Hertzer
>Computer Center University Stuttgart
>West Germany
>zrfp0128@awssn3.rus.uni-stuttgart.de
>Phone:
>++ 49-0711-685-5803

	The Luddites were an anti-technology terrorist movement in Great
Brittan and the United States during the Industrial Revolution era.  They
were objecting to the increasing automation and job displacement that the
introduction of steam powered engines and mechanical distribution systems
and power looms and other machinery entailed.
	They sabotoged machinery, rioted, destroyed machinery and the homes
of people they disagreed with in a reign of terror not too unlike some of
the riots that the US suffered in the late 1960's.  The distance of history
lets many people feel complacent about the use of the term Luddite.

	To apply the term Luddite to oneself or to imply that anyone
using this wonderful technology that we have access to could be a Luddite
was a little more than I could accept with equanimity.  A lot of high
school students that I know are a lot more mature and sophisticated than
a lot of the college students that I know.  The stereotyping of ALL high
school students with Mr. Earles broad brush is also an irresponsible act.

	In turn, I was irresponsible in posting the flame.  To keep it from
turning into an extended flame war, I directed the followups to /dev/null
(a unixism for nowhere) and cross-posted to alt.flame to alert the readers
that it was a flame.  It was a waste of the net bandwidth and I apologize
to you for mixing you up in it.  I apologize to the rest of the group for
their being subjected to further non-relevant discussion. 

	In another article, someone (I think it was Sean Barrett) takes me
to task for the redirect and not reading alt.flame.  The redirect was intended
to cut off more flameage, and I read alt.flame (when I can get it - my feed
does not usually include it) but I figure that cross-posting to alt and
comp is generally rude. (Mea culpa, I was rude, but not crude.)
-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...mcnc!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu     ggw%wolves@mcnc.mcnc.org
[The line eater is a boojum snark! ]           <standard disclaimers apply>

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 06:23:11 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   rfc's by name, not by number

I don't know about you, but I find it difficult to remember which RFC
is which when they all have numbers.  I mean hey, 959 doesn't mean
anything to me, but FTP does.  And quick, which number is Host
Requirements?

A number of sites collect RFCs and put them on-line for public access.
I've decided to do the same on "ftp.math.lsa.umich.edu", directory
pub/rfc.  But instead of collecting them by number these ones have
sensible names, i.e. "internet-numbers", "avian-carriers", "rip",
"ftp" etc.  When sensible I'll use names carried over from internet
drafts.

I would encourage other sites which carry RFC archives to do the same.

--Ed

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 12:04:48 GMT
From:      generous@dev.dtic.dla.mil (Curtis Generous)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: B1 secure TCP/IP

paul@cscnj.UUCP (Paul Moody) writes:

>I have been asked to track down info on a DOD B1 secure implementation
>of TCP/IP. The requestor believes that a company called ADAMAX(sp?)
>produces such a beast but has not been able to track them down.

Taken from the '89 Summer USENIX proceedings:

		Addamax
		1355 Piccard Drive, Suite 300
		Rockville, MD 20850
		(301) 590-0090

--curtis
-- 
Curtis C. Generous
Defense Technical Information Center (DTIC)
ARPA: generous@dev.dtic.dla.mil
UUCP: {uunet,vrdxhq}!dev!generous

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 13:05:07 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: rfc's by name, not by number

In emv@math.lsa.umich.edu (Edward Vielmetti) writes:
> instead of collecting them by number these ones have sensible names,
> i.e. "internet-numbers", "avian-carriers", "rip", "ftp" etc.

	Isn't that what index files are for?  Is it really that hard to
get the latest index file and grep for the subject you want?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Don't Worry, Be Happy"

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 14:22:49 GMT
From:      jek@fibercom.COM (Jim Kristof)
To:        comp.protocols.tcp-ip
Subject:   RFC1063, RFC1122

Can anyone tell me which commercial TCP/IP implementations
incorporate rfc1063 and rfc1122?  For vendors not currently 
supporting them, which have made announcements to do so?

If there's enough response, I'll summarize back to the net.


-- 
James E. Kristof                    INTERNET: jek@fibercom.com
FiberCom, Inc.                      UUCP: ...!uunet!fibercom!jek 
P.O. Box 11966                      PHONE: +1 703-342-6700,  800-423-1183
Roanoke, VA 24022-1966              FAX:   +1 703-342-5961

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 18:37:33 GMT
From:      escher@Apple.COM (Michael Crawford)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcasting Adreess and Subnets

In article <379@jove.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul) writes:
>In article <16240@smunews.UUCP> merlin@csvax.seas.smu.edu (David Hayes) writes:
>>
>>I'm working on a printer accounting program that runs throughout
>>our (subnetted) campus network.  It uses a client-server
>>architecture.  There are multiple, redundant servers.  I wanted
>>our system to be able to find the servers by broadcast [...]


Perhaps you could have the print servers register themselves with the name
server somehow, and then query the name server.
-- 
Michael D. Crawford
Oddball Enterprises
606 Modesto Avenue
Santa Cruz, CA 95060
oddball!mike@ucscc.ucsc.edu

Consulting for Apple Computer Inc.
escher@apple.com
Applelink: escher@apple.com@INTERNET#

The opinions expressed here are solely my own.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 90 20:50:56 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   TCP/IP Versus LU 6.2 For Building Client-Server Applications

If you were building a client-server application between a PC
running under Novell or LAN Manager and an IBM mainframe, and if
you were using a programming API that mapped equally well to both
TCP/IP and LU 6.2, then which would be the transport of choice:
TCP/IP or LU 6.2?  I've heard a number of reports that performance
in client-server apps using LU 6.2 is pretty ugly, but I have no
data to prove that TCP/IP would be any better.  Anyone with
experience or ideas on this?

Thanks,
Will              (sun!portal!cup.portal.com!Will)

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 90 03:33:58 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc
Subject:   Release 6.x of the Clarkson packet drivers is now available.

Release 6.x of the Clarkson packet drivers is now available.  A portion
of the read.me file is appended, followed by the availability information.
I believe that all the drivers are 99% bug-free.  It is a moot point as I
have been told by my boss (who was told by his boss) to spend less time
on networking software, and more time on my real job.  [If I had $5 for
every machine running the packet drivers, this would *be* my real job,
and Clarkson would be glad of the income.]  If you wish to thank my
boss for the time he has allowed me to put into this project, his E-mail
address is "bray@sun.soe.clarkson.edu".

I will not have time to act on any bug reports.  Nonetheless, send them to
me -- I will put them in a file called "bugs" that will be kept on
sun.soe.clarkson.edu in the same directory as the drivers.

Summary:
	New drivers: ni6510, at&t, arcnet, ipxpkt, nb, ne2000.
	New utilities: pktmulti, pktsend, pktstat.
	Bugs fixed: 3c505, 3c503, wd8003e.

		The Clarkson packet driver collection

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, Fido file request, and by modem.  They come in two flavors
-- executables only (drivers.arc), and source+executables (driverss.arc).
All of the following instructions apply to both drivers.arc and
driverss.arc.

FTP:

sun.soe.clarkson.edu:/pub/ka9q/drivers.arc
grape.ecs.clarkson.edu:/e/tcpip/drivers.arc

Archive-server:

Send mail to archive-server@sun.soe.clarkson.edu and put the following
command as the body of your message:
	help

This will send you a help message.  Reading this help message will tell
you how to fetch the packet drivers.

Modem:

Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
1200/2400 Baud, 24 hours.  Change to file area 24 and download drivers.arc.

Opus:

260/360 in the Nodelist.  Drivers.arc is file requestable.
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 90 15:28:33 GMT
From:      wclark@csi.3Com.Com (Wayne Clark)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus LU 6.2 For Building Client-Server Applications

In article <28870@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>If you were building a client-server application between a PC
>running under Novell or LAN Manager and an IBM mainframe, and if
>you were using a programming API that mapped equally well to both
>TCP/IP and LU 6.2, then which would be the transport of choice:
>TCP/IP or LU 6.2?  I've heard a number of reports that performance
>in client-server apps using LU 6.2 is pretty ugly, but I have no
>data to prove that TCP/IP would be any better.  Anyone with
>experience or ideas on this?
>
>Thanks,
>Will              (sun!portal!cup.portal.com!Will)

Will -
     Being an LU 6.2-bigot, I'd have to say that if you're looking for 
scaleable Client-Server applications, you might want to take a long, hard 
look at LU 6.2.  LU 6.2 support can be found today on all platforms: 
Personal Computers (PC, PS/2, ...), minicomputers (AS/400, VAXen, RS/6000,
DG, Prime, NCR, ...), as well as mainframes (all S/370-class machines).
The rub is that the APPC APIs are all mutually incompatible with one another.
(This is supposed to be one of the major salvations of SAA!)

     Even though TCP is pretty commonplace today as a transport protocol and
the sockets API its programmatic interface of choice, IBM has treated TCP/IP
as a poor cousin of SNA (#1) and OSI (#2) (at least for the time being).

     Being a latecomer into the TCP/IP world, IBM has been playing a pretty 
good job of catchup (they ship more TCP/IP products than any other vendor).  
They had a pretty slick booth at Interop '89 last year here in San Jose, 
showing interconnected mainframes, PS/2's, AS/400's.  At that time, several
of the critical elements of the TCP/IP network were either "Prototype" or 
"Research Projects".  They have turned many of those early implementations 
into products since last autumn.

    When IBM talks about having TCP/IP on a mainframe, they mean they support
the transport protocol and a limited number of services.  They say things like
"Use TCP/IP and SNA side-by-side".  If you look at what this statement really
means, IBM is providing dual solutions for some computing applications 
(e.g. electronic mail, terminal emulation, ...).  But TCP/IP and SNA are not
treated equally.

     HERE IS THE CATCH:  The family jewels (i.e. DB2, CICS, DISOSS, ...) are
accessible only through SNA.  Now, I imagine your client-server application
might want to get to a mainframe database at some point.  If this is the case,
look real hard at LU 6.2 and ask tough questions to IBM regarding their TCP/IP
for MVS and VM.

    Of course, it is possible to use the APPC API and route APPC level 7
protocols over non-SNA networks (i.e. APPC over non-LU 6.2 transports), but
that is a separate discussion.
--------------

Wayne Clark
Senior Architect
IBM Connectivity Operations, 3Com Corporation
(formerly Communications Solutions, Inc.)

phone:  408/562-6967
EMail:  Wayne_Clark@SPD.3mail.3Com.COM
                 -or-
        {nsc,bnrmtv,epimass}!csi!wclark

#include <std/disclaimer.h>

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 90 15:14:42 GMT
From:      kevin@msa3b.UUCP (Kevin P. Kleinfelter)
To:        comp.dcom.lans,comp.protocols.ibm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   LAN Hopping via 370

How can one communicate from a PC on an IBM Token-Ring network to a PC
on ANOTHER IBM Token-Ring network, when the two networks are connected
only by an IBM 370?

i.e. We have

PC-TokenRing-3174Controller-3705FrontEnd-IBM370-3174Controller-TokenRing-PC
                                        *
Everything to the left of the asterisk is in England, and everything to
the right is in the USA.

The following ideas have been suggested, and have the indicated problems:

1. TCP/IP. (IBM says we would have to have a 370 in England too.)
2. LU 6.2 (Won't connect from on Token-Ring through 370 to another Ring.)

What we would like is to have the two token-rings appear to be connected 
via a simple bridge or gateway.  Surely other multi-national companies have
addressed and solved this problem!  

-- 
Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347
gatech!nanovx!msa3b!kevin

"Don't hold your finger on the button if the motor ain't goin' roundy-roundy."

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 90 18:23:55 GMT
From:      jhanley@oracle.com (John Hanley)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast storm (Dynix sends ICMP back to rwho sender)

In article <547@janus.Quotron.com> todd@janus.Quotron.com (todd) writes:
>If you must have multiple broadcast groups on one physical net, then *try*
>having your vendors fix their software to conform to RFC1122, page 39.
>"An ICMP error message MUST NOT be sent as the result of receiving: ...
>a datagram sent as a link-layer broadcast..."

Dynix 3.0.17 and earlier is a prime offender of this clause on our
international 1000-node bridged network.  Every time a Sequent that is
not running rwhod encounters an rwho packet addressed to ether addr
ff:ff:ff:ff:ff:ff and IP addr 130.35.0.0, it tries to deliver the packet
to rwhod, fails, and unicasts a "port unreachable" ICMP back to the
sender.  In all fairness, a bit of exegesis was needed to correctly
interpret the previous RFC, and at least Dynix never _broadcasts_
an ICMP, unlike _some_ IP implementations on our net.

I have submitted a mailbug to Sequent Engineering, and they agree that
Dynix should be fixed, but it will probably happen in a maintenance
release after Dynix 3.1.  They say the problem is corrected in PTX, so we
will probably be exploring that brave new world before Dynix does it
properly.  'Course, we'll probably be subnetted by then so that broadcast
problems will be nearly a thing of the past... 8^)

                            --JH, system programmer, Oracle unix administration

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 90 21:51:33 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast storm (Dynix sends ICMP back to rwho sender)


	I ported (and added multiprocessor support for) full 4.3 networking
in our DYNIX system a few years ago and a couple years ago I added all of
the 4.3 Tahoe changes. Aside from the locking code and a couple minor
rearrangements to eliminate races, the sources diff reasonably with the
Berkeley code (unlike the distributed Sequent sources), so updates are
fairly trivial as well.
	We've done about 10 distributions of the source last I heard and I
created one binary-only distribution of the TCP fixes and enhancements. We
also have virtually all 4.3, 4.3T and later upgrades in the kernel and user
code and we've been running it in production for years. If you have DYNIX
and want to get some of our stuff, you can send me mail and I'll forward
your requests to people who can do something about it. I can't make any
guarantees, since we aren't in the software distribution business, but it
doesn't hurt to ask.
	If you don't have a DYNIX source license, the answer is probably
"no," but send me mail anyway and mention that. We might manage a binary
distribution, too.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 90 02:01:06 GMT
From:      rbp@well.sf.ca.us (Bob Pasker)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: TCP/IP Versus LU 6.2 For Building Client-Server Applications

wclark@csi.3Com.Com (Wayne Clark) writes:

>In article <28870@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>>If you were building a client-server application between a PC
>>running under Novell or LAN Manager and an IBM mainframe, and if
>>you were using a programming API that mapped equally well to both
>>TCP/IP and LU 6.2, then which would be the transport of choice:
>>TCP/IP or LU 6.2?  
>Will -
>     Being an LU 6.2-bigot, I'd have to say that if you're looking for 
>scaleable Client-Server applications, you might want to take a long, hard 
>look at LU 6.2.  
>[wayne talks about how many platforms LU62 runs on, and their dissimilar APIs]
>[wayne talks about TCP being a poor cousin in IBM land]
>[wayne talks about the catch:The family jewels (i.e. DB2, CICS, DISOSS, ...)
>Wayne Clark, Senior Architect,IBM Connectivity Operations, 3Com Corporation

These are EXCELLENT points for choosing LU6.2 over TCP/IP. A real
question I have for you, Will, is: are you going to be talking to a
CICS application or some other "family jewel" sub-system that only
speaks LU6.2?  if so, then LU6.2 is your only choice, without going
through hoops.  If your application is VM-based or an MVS task, then,
IMHO, you could probably choose TCP/IP. I would.





-- 
- bob
;-----------------------------------------------------------------
; Bob Pasker, San Francisco, CA	 	| rbp@well.sf.ca.us
; +1 415-695-8741			| {apple|pacbell}!well!rbp

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 90 13:02:00 GMT
From:      gartley@ALDNCF.ALCOA.COM ("J O GARTLEY")
To:        comp.protocols.tcp-ip
Subject:   tcp/ip for msdos

Recently, I have downloaded a number of versions of tcpip for an MS/DOS system.
I have the NCSA version 2.3beta that uses packets as well as the hardcodeed 
other drivers.  I also have a version of CMU form harvard that is to use\the 
packet drivers from clarkson also.

I have also downloaded cmu from simtel20 area.  I find reference to
netdev.sys and custom program...

I have been able to get the ncsa version working with my 3c503 board fine by
using the command  3c503 0x7e 3 0x300 then running either telbin or ftpbin.

I then tried to use the cmu package from harvard but there seems to be a 
reference to netdev.sys and I have look at what little documention I can
find but since I am a novice user on the MS/dos system I am not sure what to
do.

Is there any documentation on these different packages...
That is like ... Steps to follow to install/use these different packages
on a system.

Please help.

Thank You,
John Gartley
gartley@ncf.al.alcoa.com

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 90 18:53:02 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

There are no official certification procedures.  If a vendor of SNMP
software has an agent or manager on the Internet that they wish to test,
they can drop a note to the snmp@nisc.nyser.net list and ask for people
to help out.  To be added to this list drop a note to
snmp-request@nisc.nyser.net.

Usually an agent can be check out pretty quickly.

/mtr

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 90 20:28:16 GMT
From:      sastdr@sas.UUCP (Thomas David Rivers)
To:        comp.protocols.tcp-ip
Subject:   Latest PD SLIP, where to get it?



   I have a fledgling network starting up at home, between a '286 XENIX
box, an 8086 Minix box and a '386 box.  I would like to get SLIP
working between them all.

   I have the slipware sources (rev 3) for a Sun, but they aren't all
that helpful, since none of these boxes has sockets.  I have seen references
to dialup SLIP version 4, and a port of Phil Karn's ka9q to unix, and
have even seen talk of a port of a subset of ka9q to minix.  But can't seem
to locate them on any archives.

   I would like some public domain source, for porting to minix, and for
keeping the implementation consistent across the platforms.


   Finally, I don't have direct access to ftp, so if anyone knows of
some anonymous UUCP or archive servers which has what I'm looking for,
please let me know.

	- Thanx in advance -
	 - Dave Rivers -
-- 
|  Time sharing: The use of many | - Dave Rivers - SAS Institute, Cary NC |
|   people by the computer.      |   UUCP: ...!mcnc!rti!sas!sastdr (work) |
|				 |         ...!mcnc!ponds!rivers   (home) |

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 90 22:34:12 GMT
From:      drubin@polyof.poly.edu (A1 dave rubin (single) )
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   POP 3 server

I am having trouble running the Berkeley POP-3 server on our SUN 3's
under SunOS 4.0.3.  I have version 1.5 of "popper" which was retrieved
from lilac.berkeley.edu.

The source compiles OK, but produces a segmentation fault when run.

Any ideas on what is wrong?  Are there any other POP-3 servers out there?
We are interested in something simple.

Thanks.. Please respond via E-mail.

--
Dave Rubin
Polytechnic University
Internet: drubin@polyof.poly.edu
Bitnet:   RUBIN@POLYGRAF

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 90 06:58:12 GMT
From:      JACKSON@NIC.DDN.MIL (Marc Jackson)
To:        comp.protocols.tcp-ip
Subject:   [efb@suned1.Nswses.Navy.Mil (Everett F. Batey II): Locked on the MILNET]

Return-Path: <efb@suned1.Nswses.Navy.Mil>
Received: from suned1.Nswses.Navy.Mil by NIC.DDN.MIL with TCP; Mon, 16 Apr 90 02:18:40 PDT
Received: by suned1.Nswses.Navy.Mil (4.1/Nswses4.0.3_900324eb)
	id AA05369; Mon, 16 Apr 90 01:24:14 PDT
Message-Id: <9004160824.AA05369@suned1.Nswses.Navy.Mil>
From: efb@suned1.Nswses.Navy.Mil (Everett F. Batey II)
Date: Mon, 16 Apr 90 01:24:12 PDT
Reply-To: efb@suned1.Nswses.Navy.Mil ( Everett F Batey II )
X-Orgztn: NSWSES 4V43 Port Hueneme, CA 93043 - Opinions: Mine Alone
X-Phones: 805/982-0311 (A/v: 551-0311) Res: 985-5326 (Ans)
X-Mailer: Mail User's Shell (7.0.0 12/10/89)
To: action@nic.ddn.mil
Subject: Locked on the MILNET
Cc: ron@suned1.Nswses.Navy.Mil

Some months ago, we were static routed ( vaxb.nswses.navy.mil ) to marina
del rey mb gateway.  It was real broken and we could only reach the milnet.

Well our NSC moved vaxb to moffett..mb.  It still answers ping.  HOWEVER,
we can reach almost NO hosts off the MILNET.  Is DDN out to lunch, our
gateway out to lunch, are we out to lunch .. all our internal routing hosts
are obviously still hard routed to our only route .. vaxb.  Only way
out of MILNET is to log to some other host.  Big mail queue building up.

Really hate to hack my sendmail.cf file each few months.  Any help available ?

/Ev -- DNS, Namespace hacker ( EFB15 )/.

-- 
 +  efb@suned1.nswses.Navy.MIL efb@elroy.JPL.Nasa.Gov  efb@voodoo.bitnet  +
 +  efb@suned1.UUCP | Gold Coast Sun Users | Vta-SB-SLO DECUS |  WA6CRE   +
 +  Statements, Opinions, MINE, NOT Uncle Sam_s | News Postmaster DNS guy +
-------

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 90 12:29:31 GMT
From:      pansiot@isis.u-strasbg.FR (Jean-Jacques Pansiot Departement d'Informatique, Universite Louis Pasteur Strasbourg FRANCE)
To:        comp.protocols.tcp-ip
Subject:   (none)

From daemon Fri Apr  6 10:15:25 1990
To: pansiot
Subject: small site

Here in Strasbourg, we are in the process to connect small sites
to our University network.
By small site, I mean a few PC , Mac, and may be one or two
Unix machines. Theses sites are off campus, so we need leadse lines,
like 9600 b/s. We mostly use TCP/IP, so a TCP/IP link would be
sufficient.
My question is : How to connect these sites cheaply (for example using
PC's and public domain software ?).
I assume that the link over serial line would be SLIP.
Is there a public domain IP router between Ethernet and SLIP?
On PC running MSdos ? on Unix machines (Sun for example)?
Finally, on these sites, there may be a localtalk net.
Is there a public domain router between Ethernet, SLIP, localtalk
(I know that there are localtalk cards for PC).
Thanks a Lot
Jean-Jacques Pansiot,  Universite Louis Pasteur, Strasbourg, FRANCE
Email: pansiot@isis.u-strasbg.fr
Tel:  (33) 88 41 64 28
.

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 90 13:25:02 GMT
From:      jbasara@ssdc (jim basara)
To:        comp.dcom.lans,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec
Subject:   Need SLIP over LAT !!!!


 I am in need of a product to implement SLIP over LAT.  Does anyone know
 of such a product????  The host system is a MVax II.  I would appreciate
 any response to point me in the right direction.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 90 15:19:59 GMT
From:      russotto@eng.umd.edu (Matthew T. Russotto)
To:        comp.protocols.tcp-ip
Subject:   Re: small site

In article <9004171229.AA07722@ISIS.U-STRASBG.FR> pansiot@isis.u-strasbg.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes:
>
>Here in Strasbourg, we are in the process to connect small sites
>to our University network.
>By small site, I mean a few PC , Mac, and may be one or two
>Unix machines. Theses sites are off campus, so we need leadse lines,
>like 9600 b/s. We mostly use TCP/IP, so a TCP/IP link would be
>sufficient.
>My question is : How to connect these sites cheaply (for example using
>PC's and public domain software ?).

I don't know about the IBMs, but at dustbin.cisco.com there is a freely
available SLIP for the mac.  (It is based on NCSA Telnet, and claims not
to be public domain).  A/UX machines come with SLIP.
>Is there a public domain IP router between Ethernet and SLIP?
>On PC running MSdos ? on Unix machines (Sun for example)?

I think 'slattach' is what you are looking for-- it exists on the Ultrix
systems here, and on A/UX, but I don't know about suns or PCs.

>Finally, on these sites, there may be a localtalk net.
>Is there a public domain router between Ethernet, SLIP, localtalk
To connect Ethernet to Localtalk, you need some hardware, like a Kinetics
Fastpath.
--
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 90 17:35:20 GMT
From:      "Gilbert_ho.osbunorth"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for MVS


Dave,

Please forward a summary of the responses you get to me.
I am also very interested in this subject simply because my past IBM experiences.

Thanks.

Gil 

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 90 20:00:42 GMT
From:      hayes@Apple.COM (Jim Hayes)
To:        comp.protocols.tcp-ip
Subject:   Router Hardware Reliability

I am looking for first hand hardware failure experiences with TCP/IP
routers, especially those manufactured by cisco and Network Systems
Corp.

We are making some purchase decisions and are interested in "comparing
notes" with other sites, to determine if our failure experiences
are typical.  If you havn't had any failures I'd like to hear about
that as well.

Please respond via e-mail.  I will summarize if people seem interested in 
the results.

I think this kind of information would benefit all of us.

Thanks.

-- 
Jim Hayes, TCP/IP Weenie, Advanced Technology Group, Apple Computer, Inc. 

Inet: hayes@apple.com
UUCP: {amdcad|decwrl|ames}!apple!hayes
AppleLink: HAYES

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 90 21:54:57 GMT
From:      HOSTMASTER@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   the use of profanity

The TCP-IP mailing list exists for the common good of promoting
knowledge about the TCP/IP protocol suite.  Because correspondence on
the list occurs in an unmoderated honor system environment, it is
important that all correspondence to the list be made in a
professional manner.
-------

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 02:03:18 GMT
From:      ziegast@umd5.umd.edu (Eric W. Ziegast)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Re: POP 3 server

>Are there any other POP-3 servers out there?
>We are interested in something simple.

Yes, MH. Definately MH.
The current release is MH-6.7
Compiles on virtually all Unix systems.
POP-3, bulletin boards, and NNTP are servers which MH can function as.
And you get a bunch of nifty mail handling routines as well.

Approx 5.5MB source, 2.8MB installed on Sun 4 /w shared libs.

The supporting newsgroup is comp.mail.mh .
Source can be found at two ftp sites.
	ics.uci.edu
	louie.udel.edu

Eric Ziegast
ziegast@eng.umd.edu
{uunet}!eng.umd.edu!ziegast
ziegast@umdd.bitnet

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 04:51:13 GMT
From:      ksoll@DB0TUZ01.BITNET
To:        comp.protocols.tcp-ip
Subject:   /etc/hosts, DNS, sendmail.cf, YP ?


Hi folks,
first I want to explain my scenario: let's say I have some hundred
lovely UNIX-Workstations (AIX, DomainOS, HP-UX, Ultrix, Unicos, 386/ix,
etc.). They are all connected through a campus wide Ethernet and all
speak TCP/IP. Then I have a mailserver (Sparc, SunOS) who has to do the
following:
 - act as mail-gateway between SMTP and X.400
 - act as mailforwarder for all my workstation, so that they don't
   have to know, where hey will find all their mail partners
 - act as connector to the Internet
 - act as Domain Name Server for a big part of my domain.
Screening all my TCP/IP-implementations some questions arose:
1.) Should /etc/hosts contain full qualified Domain Style Names or just
    UNIX-nodenames? Some implementations need a valid nodename-entry
    to set up the interface with ifconfig, some sendmail.cf need FQD to r
    reach the hosts if they are not in the same domain. (I have a Cray
    nearby in another domain).
2.) If I set up Domain Name Service I cannot provide short nicknames in o
    other domains, so hacking ip-numbers would be easier to use
    telnet and ftp.
    Some implementations do  not fall back to /etc/hosts if the
    nameserver has no answer. Am I missing something?
3.) Some people here use Yellow Pages (YP). If I am right the
    YP-host-maps are derived from /etc/hosts. So what if the YP-domain
    and the DNS-domain are different?
    Again the question: UNIX-nodenames or fully qualified DNS-
    domainnames ?
    What can I assume when they do a gethostbyname()? Will the answer
    come from YP, DNS, /etc/hosts or have I to set up a separate table
    for sendmail?
So the things seem to be complicate. I would like to give my users
some useful and short informations to set up their machines:
- if you want to use /etc/hosts only I'll give you a valid file,
- if you want to use DNS do the following (...)
- if you want to set up SMTP (no UUCP concerned here) I give you a
  general sendmail.cf,
    fill in your hostname
    fill in your (sub-)domainname and that's it,
- if you have YP running consider the following things (...)

My last question therefore is: can I manage the above mentioned within
1990 or shoul I wait some time or is it impossible to get all four b
beasts under one hat?
Any ideas, informations and hints are very appreciated.

Thank you for your patience,
Wolfgang Ksoll    Computer Center, Techn. Univ. of Berlin, Germany
                  ksoll@db0tuz01.bitnet

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 08:14:04 GMT
From:      nomann@rimfaxe.diku.dk (Ole Nomann Thomsen)
To:        comp.protocols.tcp-ip
Subject:   Re: socket connection to printer (HELP wanted)

Dear all, about one week ago, I posted this question:

> Configuration (probably more data than needed here):
> Xenix 386, Excelan 3.5 Netsoftware
> CS200 Connectionserver runnning SW/200-TCP-NCS/AT Vers. 3.2
> One mannesman laserprinter connected to the former, 9600 Baud, Xon-Xoff.
>
> I have a program, that sends to the printer, via the network. It works
> by connecting a TCP stream socket to a port on a CS200 connection-server,
> and sending the data throught that.
>
> Problem:
> If I just send the data, and then close down the connection, some data is
> lost. (Probably the data, that was "in transit" when I closed). This
> happends _Even_though_ the SIOCGLINGER-ioctl() call returns 0xFFFF, which
> is supposed to mean that the connection stays open until all data has been
> acknowledged.

As I promised, here follows a summary of the answers:

Aparrently the problem is in the way the TCP/IP to RS232 connection 
works. When my client-program closes down, it terminates the telnet-
instance(word?) on the ConnectionServer. The TCP stream-socket only 
guarantees, that the data will reach the ConnectionServer (which it 
does), but not that it will reach the other end of the RS232 connection.

So, when the telnet has received the last data, it has no second thoughts
about termininating immidiately, discarding all left data. This is in no
way contradictory to the SIOCGLINGER result.

I was suggested the following work-arounds:

     1. Run the printer slower so it never uses flow control.

     2. Dump a K or so characters you don't care about at the end of
        the file, but before you close the connection.  This way, the
        characters the cs200 drops on the floor just don't matter.  I
        use nulls or deletes, depending on the printer.

     3. If you could arrange a Telnet connection to your printer
        instead of a raw TCP connection (may be possible with your 
        ConnectionServer?), then your client program could send a 
        Telnet "DO TIMING-MARK" and wait for either a "WILL" or "WONT" 
        TIMING-MARK from the server. Even in the case of the "WONT",
        the data has at least all gotten to the server, even if it 
        hasn't all been printed yet...

     4. Use the sleep(60) (sleep-one-minute, that is) in the server.
        when it has sent the data.

Ad 1: This will probably work, but its too slow.
Ad 2: This is essentially the same as sleep() (i think).
Ad 3: As far as I can see, this only guarantees that the data wil
      reach the ConnectionServer, which it already does.
Ad 4: I'm gonna stick to this one, perhaps with a sleeptime, that
      is a function of the amount of data sent.

I like the answers I got, because they 1: Convinced me that the stream-
socket and the ioctl() functioned properly and 2: Showed me that it
wasn't me, that was stupid, because I couldn't make it work (;-)

Many  thanks to: fmayhar@hermes.ladc.bull.com, DSMITH@oregon.uoregon.edu
rpw3%rigden.wpd@sgi.com and MINER@enr.prime.com for their kind help.

PS: Sorry, if this is posted twice too, our computer-department is
working at the problem, I think.


"Very good". - Johan Gambolsputty De Von AusFernSplendenSchlitterCrasCrenBonFriediggerDingleDangleDongleDungleBursteinVonKnackerThrasherAppelbangerHorowitzTicolensicGranderKnottySpelltinklerGrandlichGrumblemeyerSpelterwasserKurstlichHimble
EisenBahnWagenGutenabenBitteEineNurnburgerBratwurstleGespurtenMitzWeimachelUberHundsfutGumberaberSchonendankerKalbsFleischMittlerAuche Von Hautkopf of Ulm.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 10:31:01 GMT
From:      dirk@dksoft.incom.de (Dirk Koeppen)
To:        comp.protocols.tcp-ip
Subject:   Sending large UDP Datagrams

Hi there !

Has anybody a nice solution to the problem with sending UDP
datagrams > 1024 Bytes ? 

I'am looking for a replacement for recvfrom(3i) and sendto(3i)
which allows one to send large datagrams but there is no need
that they always arrive. There's only the need that they arrive
complete and fairly often.

cu,
dirk@incom.de

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 13:31:01 GMT
From:      dvincent@actrix.co.nz (David Vincent)
To:        comp.protocols.tcp-ip
Subject:   MIPS X.25 TCP/IP

Hi,

Hopefully this won't have gone out before - we seem to be having a few
problems sending mail at another site. Here goes from this one.

We have a few MIPS M/120's with Emulux X.25 cards. We bought them on the
understanding that they could handle TCP/IP. Unfortunatly they dont.

Does anyone know of any X.25 cards that the MIPS can handle that does
support TCP/IP over X.25? If the worst comes to the worst does anyone
know of a company that could possibly write the needed code. We've
spoken to a few people in the States and the impression they gave
was that it's not really a big thing over there.
 
Thanx.

David Vincent            Ministry of Agriculture and Fisheries
dvincent@actrix.co.nz    New Zealand

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 14:48:44 GMT
From:      ables@lot.ACA.MCC.COM (King Ables)
To:        comp.protocols.tcp-ip
Subject:   info on Netwise?

Apologies if this has already shown up here, but I don't think it has.
We've had a migration of news from one machine to another here and
things weren't working quite right for a few days.

I have been told that a company by the name of Netwise makes a 
"networking product" that might help with something we're doing.
Unfortunately, that's all the information I have.  I don't even
know if or how it fits with TCP, so I don't know if this is even
a good place to ask, but even if it's unrelated, someone here may
know something.

If anybody could give me a contact and/or a phone number or any
information or opinions about them or the product, I'd appreciate it.

-----------------------------------------------------------------------------
King Ables                    Micro Electronics and Computer Technology Corp.
ables@mcc.com                 3500 W. Balcones Center Drive
+1 512 338 3749               Austin, TX  78759
-----------------------------------------------------------------------------
"Hello Bennie, it's your Uncle Bingo.  Time to pay the check." -- The Joker

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 17:04:19 GMT
From:      jbvb@ftp.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Sources for NDIS drivers

In article <8195@cognos.UUCP>, craigs@cognos.UUCP (Craig Statchuk) writes:
> Does anyone know where I can obtain NDIS drivers for 3Com ethernet
> cards (3C501, 3C503, 3C505 AND 3C523)?  

Aside from 3Com themselves, the Microsoft collection is the only means
I know of.

>   1: Do such drivers even exist?

Yes.  We've seen numerous versions since early 1989.  They've gotten better.

>   2: Is this a good way to achieve hardware independence?

Yes, as long as you mean indepenence from the details of a specific
Ethernet interface.  Don't expect it to provide media independence (as
in 802.5 vs. 802.3).  Our Packet Driver specification is an
alternative (DOS only).  Novell's ODI spec would also do the trick,
whenever drivers conforming it start to appear.
-- 
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 17:06:37 GMT
From:      dcrocker@nsl.dec.com (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

This is as good a time as any to describe a capability/service that we have recently
established:

There are two kinds of "product-prooving" mechanisms that get used.  One is
"conformance" oriented and usually involves formal certification.  Operationally,
it entails the exercise of 'objective' tests against one's implementation.  The 
assumption is that if each implementation passes muster, then implementations
can interoperate.

The other approach -- and there is nothing preventing the use of both -- is
to get down into the trenches and test actual implementations against each other.
This is generally called interoperability testing.  It involves
cooperative, constructive
warfare, in which implementors basically try to break each others' software, in
the spirit of having this happen in a laboratory environment, rather than in a
customer's network.  (On the theory that it WILL happen somewhere.)

The problem is that it often is difficult to find places to conduct
such tests, except
at an occasional conference or trade show, such as the once-a-year Interop.

The Network Systems Laboratory has allocated a portion of its space in beautiful
downtown Palo Alto, near the Stanford campus, to provide a general service to the
technical community for the purpose of interoperability testing.  We are calling
it OpenLab (sm).  Its primary feature is that it has convenient access, but is
isolated from the rest of the Digital facility, so that participants do
not constantly
have to be escorted.  I.e., OpenLab(sm) is neutral territory for the conduct of
interoperability tests, among a collection of vendors.  There is, in fact, no
particular requirement that Digital be one of the members of the testing group.  We
do, however, prefer that such activities be sponsored by a 'group' such
as a standards
body.

This is sufficiently new and is the result of an "opportunistic"
response, rather than
a detailed plan, that many of the details of its operation will be determined by
experience, so that early users of the service will need to take a
flexible approach to
it.

Please note that this is not a "business."  There is no intent to garner interesting
revenue from it, though I do expect that we will eventually have to charge a small
usage fee, to recover costs.  NSL is part of corporate research and does not have
heavy funding to pay for the overhead of this, though we are delighted
to provide the
space, power, air conditioning, and restrooms.

Another point of clarification:  As of now, OpenLab(sm) is space, not computers.
That is, there is no intent to fill it with interesting equipment that
you can walk in
and test against.  It has no permanent footprint of equipment.  This
might change, over
time, but is not currently planned.  All equipment must be provided by
the participants.

OpenLab(sm) is intended to replace the garage that served as neutral ground for
the SNMP testing that was done prior to the last Interop...

Dave

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 17:28:54 GMT
From:      carla@boulder.Colorado.EDU (Carla Mowers)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP time delay


My company ports an RPC toolkit to a variety of platforms, including many UNIX
systems. We have observed the following anomaly on UNIX BSD systems:

After a TCP listener has been created then shut down, a new listener can not
be bound on the same socket for some amount of time. The new listener will
get the error, "Address already in use."  The amount of time until the address
can be re-used varies on different systems.  It is typically about a minute,
but times as low as 20 seconds or as high as 2 minutes have been observed.
Also, the amount of time appears to be inconsistent--different amounts of
time will be observed on the same system.  This is usually not an issue in
production software--the service is brought up at boot time. However, it can
be a distraction when debugging networking code.

Questions:

1. Is there something in the nature of TCP/IP which is requiring that there be
   this much of a real-time delay? 
   
2. Doing a setsockopt(SO_REUSEADDR) appears to let us work around the problem.
   Are there any nasty side effects to using this call? The manual
   (specifically, our Sun man pages and Networking Guide) is fairly ambiguous
   about this function.

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 90 17:38:31 GMT
From:      lmorales@HUACHUCA-EMH8.ARMY.MIL ("Luis F. Morales,Jr. ")
To:        comp.protocols.tcp-ip
Subject:   Official references to DDNX.25

To All,

I am in need of some expert help.  I need to find the official reference to
to issues that have arisen with a discussion with Unisys engineeres.  
Although I know how the following is done in order to make Unisys believe me
and implement these items correctly I must prove that there are official
documents that desribe exactly how they are implemented.  The following is
what I am seeking:

1.  The method of mapping Class B and C IP addresses to X.121 addresses.

2.  The document that describes Class B and C subnetting in reference to X.25
not Ethernet.

I have read rfc 950 that describes subnetting but Unisys argues that it refers
only to LANS, therefore Ethernet not X.25.  I believe they are wrong that LAN
as used in the rfc is a generic term, but they are correct that in most 
references to protocols referr to protocols used in Ethernet not X.25.  I have
also examined the DOD protocol handbooks which refer to Class A configurations
only.  I am still examining various RFCs, but I thought that someone else may
have allready gone through this and could save me some time.

Thanks in advance,

Luis Morales
USACEC
lmorales@huachuca-emh8.army.mil

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 00:04:44 GMT
From:      "Andrew_A._Rutz.LAX1B"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

.... to build (in a light-hearted manner) off of ecsgate's message
regarding Luddites....... 

 Mention was made of the Luddites SABOTaging mechanized equipment that in
the immediate sense had the possibility of taking their jobs.   I am
reminded of the etymology of 'sabot' - the root of 'sabotage':  'sabot' in
french (?) means 'wooden shoe'.  These people (the Luddites) were known for
wearing wooden shoes (....one of the last stronghold contingents that
refrained from paying the exorbitant costs for Air Jordans!).  Well, when
they damaged the machines (sabotage), they did it by slamming their wooden
shoes (sabots) with such force and direction that they broke the machines
!!  Get it?  

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 00:32:13 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

Speaking for myself:

	BRAVO!

I'm not sure how things can be coordinated year round to use the OpenLab
facility, but I think you'll be booked pretty solid this September...

/mtr

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 00:46:59 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   Re: SNMP agent for DEC Ultrix??

In article <44@fedeva.UUCP> bill@fedeva.UUCP (Bill Daniels) writes:
>Is anyone familiar with using SNMP to manage a DEC Ultrix machine,
>specifically the DECsystems and DECstations running Ultrix 3.1[C].  We
>have accumulated some SNMP manageable devices on our small TCP-IP
>ethernet and would also like to be able to determine that our host nodes
>are alive/not-alive.  How might I accomplish this?

The Ultrix V4.0 "Fact Sheet" posted to comp.unix.ultrix a few weeks
ago says:
    o  Network Support Enhancements
	[...]
       -  Simple Network Management Protocol (SNMP) agent reports
          network management information
I don't know if the SNMP agent software for Ultrix 4.0 will run on
Ultrix 3.1C systems.

-Jeff

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 02:35:01 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   [Andy Malis <malis@CC5.BBN.COM>: Re: IP class B and C to X.25 address translation ]

Here is what was heard (from BBN, something of an authority is such
matters) last time this came up.  I can't think of why subnetting would
have any effect on the address mapping algorithm.  cisco gear splits
class C addresses down the middle - 4 bits each for host and psn.

BillW

                ---------------

To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
cc: malis@CC5.BBN.COM, tcp-ip@SRI-NIC.ARPA
Subject: Re: IP class B and C to X.25 address translation 
Date: Tue, 19 Jan 88 13:53:06 -0500
From: Andy Malis <malis@CC5.BBN.COM>

The following message didn't seem to make it out of my host when
I sent it the first time.  Since this is a topic that comes up
from time to time, I thought I would resend it.

Andy

------- Forwarded Message

To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
cc: malis,tcp-ip@sri-nic.arpa
Subject: Re: IP class B and C to X.25 address translation 
Date: Mon, 28 Dec 87 11:44:33 -0500
From: Andy Malis <malis@cc5.bbn.com>

Barry asked the following:

        Has there been any standardization on the translation of
        Class B or C IP addresses to X.25 addresses? I am aware
        of the translation standard for Class A addresses, but
        have not seen any for B or C. 

Barry,

There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses.  The third octet of Class A addresses is
dropped completely in Class B addresses.

There is absolutely no standardization for Class C, because there
are so few local network address bits to play with.  The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net.  For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number.  It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.

Regards,
Andy

------- End of Forwarded Message

-------

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 03:28:17 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP time delay

In article <19863@boulder.Colorado.EDU> carla@boulder.Colorado.EDU (Carla Mowers) writes:
>After a TCP listener has been created then shut down, a new listener can not
>be bound on the same socket for some amount of time.
>1. Is there something in the nature of TCP/IP which is requiring that there be
>   this much of a real-time delay? 

If this newsgroup ever gets a Frequently Asked Questions posting I nominate
this as the first question.

Yes, TCP requires this time delay.  After a connection has been closed
there may still be some packets on the network from that connection.  For
instance, the acknowledgement for the FIN packet might have gotten lost, so
the other host might retransmit it.  Or an old packet that was delayed in
the network could finally arrive.  The TCP implementation is required to
keep the connection in a state called CLOSE-WAIT for a period of time, so
that it can recognize such packets and deal with them properly.

>2. Doing a setsockopt(SO_REUSEADDR) appears to let us work around the problem.
>   Are there any nasty side effects to using this call? The manual
>   (specifically, our Sun man pages and Networking Guide) is fairly ambiguous
>   about this function.

The nasty side effect is that these wayward packets can get misinterpreted,
and perhaps cause your application to misbehave.


--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 03:33:55 GMT
From:      eric@snark.uu.net (Eric S. Raymond)
To:        comp.protocols.tcp-ip
Subject:   What's a "fuzzball"?

I saw this term of art in a TCP-IP wizard's posting once but couldn't
deduce what it meant. I want it for the jargon file.

While you're at it, toss in any other TCP/IP-related hacker slang that
occurs to you. NB: I already have `ping', `martian' and `broadcast storm'.

Please reply by email.
-- 
      Eric S. Raymond = eric@snark.uu.net    (mad mastermind of TMN-Netnews)

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 05:33:31 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP time delay

barmar@think.com (Barry Margolin) writes:
....
> The TCP implementation is required to
>keep the connection in a state called CLOSE-WAIT for a period of time, so
>that it can recognize such packets and deal with them properly.

That should be TIME-WAIT.  Sorry to be pedantic, but it's my nature(*).

-Johnny TCP

(*) My nature as someone in the process of debugging a home-brew TCP/IP
implementation.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 12:35:03 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?


A little over a year ago Herb Bernstein of NYU wrote a proposal (I
believe to NASA) on the merits of "networked labs" (actually there
was a better term that escapes me right now), for the purposes of
instruction and cost effective research for one-of-a-kind labs or
labs with wide appeal but costs of tens of millions of dollars
to build.  [Of course that may describe many standard labs in certain
fields].

And of course there is the internet-old-boy philosophy of "The Internet as
Workbench" model which is very similar.

I think that having a dozen agents, a couple of NMS's, and a suite of
tools is interesting but ill focused.  The scarce critical resource here are
the really good people with a combination of theoretical understanding,
appropriate network management world view, implementation experience,
operational experience, etc., (you know, the normal suspects like Karl, Rose,
Davin, Weng, Case, Fedor, Satz, etc...).

In an adhoc manner with dozens of organizations providing either operational
or experimental agents (based on revised MIBs) on the Internet, the misc
tools available, and the people of above plugged in, there is no lab
anywhere that can touch what has already taken place in the last couple of
years.  With one simple addition the process could be made perfect and
really support everyone uniformly.  What is needed is an Internet based
snmp-lab-coordinator, the neutral person, who deciminates the information
of available agents on the Internet, knows where the tools are, coordinates
the mailing list, writes some documentation, etc...  Impose some structure
here and there is a big win.  Of course the person and processes have to
be good, of late I've seen people&process imposed on various things that
weren't quite up to snuff and things have suffered.

Now I realize that the standard rebuttal is that "my company isn't on
the Internet, so this won't work..".  Aside from my lack of desire for
publicly foisting myself off as completely neutral in this arena, the
infamous "information age" has evolved today to the point (in the US) that
any communications/information-technology company that doesn't participate
begins to look like a large reptile in a rapidly cooling environment: exhibits
for the extinct species wing of the Boston Computer Museum.  Essentially
I'm unsympathetic given the ability to join a regional network or a commercial
network provider (which I represent here in Reston, VA,the neutral Switzerland
of networking).

Marty

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 13:43:25 GMT
From:      Mills@udel.edu
To:        comp.protocols.tcp-ip
Subject:   Re:  What's a "fuzzball"?

Eric,

The "fuzzball" is indelibly etched on our institutional memory in the form
of my paper of the same name in Proc. ACM SIGCOMM 88. You may wish to add
"chernobyl packet" to your list as an IP Ethergram with both source and
desitnation Ether and IP address set as the respective broadcast address.
A "christmas tree" packet of any protocol has every single option set
(Jon Postel invented that one). The adventure continues.

Dave

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 14:09:52 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: High Schools on the Internet

Having followed this discussion with a lot of personal interest, I have
come to the following conclusion.
Considering the proliferation of BBS's offering Email services and file
services, and the average age of their users, it appears the majority has
decided that our kids should learn about computers and networking the same
way they learn about sex and drugs, on street corners.
And then we wonder why the term hacker got prostitued!!!

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 14:16:40 GMT
From:      dcrocker@WRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

Marty,

Interesting comments.

Since your note appears to be in reply to my discussion of OpenLab(sm),
I assume that the concerns you express related to OpenLab's functions.

Some observations:

You focus solely on network management software.  While that certainly
is one of the essential areas of recent and continuing activity, the
OpenLab is intended for any and all protocol interoperability testing.
If a group has developed the Networked Widget Protocol and wants to
conduct multi-vendor NWP tests, OpenLab is as available to them as it
is to the loftier, more publicized standards efforts.

Your suggestion of a "neutral coordinator" appears to be as an alternate
to a facility such as OpenLab.  While I am somewhat unclear about the
function you describe for the coordinator, since I would have thought
that the recently published NocTools list and the NIC's Vendor Guide
would provide pointers to available implementations, there certainly
is some significant thrashing about that occurs during the early
stages of mass implementation of new protocols.  I believe that your
suggestion leads to ADDITIONAL efforts, rather than to an alternate.

In a number of other discussions, by the way, I have heard suggestion
of connecting together a set of independent experimental facilities,
on the theory that a) each will have some unique resources, and b) they
would combine into a larger lab, thereby allowing some testing of
systems and protocols as they are scaled up.  Clearly, the general
assumption is that they would be connected over the Internet.  However,
there should be some concern about rogue experimental packets escaping
and doing damage to the Internet.  (In a couple of these conversations,
I have made the bizarre suggestion that the IP from these experimental
nets should be sent over the Internet in an encapsulation fashion, so
that you would have IP over IP...)

To the extent that your note indicates that there is little direct
need for a general-purpose neutral territory, for interoperability
testing, I can only assure you that the idea for OpenLab was born
strictly of need.  I assume that your recent switch into the commercial
sector will lead to your experiencing this issue increasingly.

Dave

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 14:35:45 GMT
From:      cory@mit-caf.MIT.EDU (Cory Myers)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Help with NCSA Telnet and SLIP combination


I am trying to configure an appletalk network, two ethernets, and a
serial line ip (slip) connection and having some problems with NCSA
Telnet.  The setup looks like:

     |            |--A---------------------------C--|
     |--Kinetics--|         Serial Line IP          |
     |    FP 4    |          (9600 baud)            |
     |            |                                 |
     |            |--B                           D--|
Mac--|            |                                 |
     |            |                                 |
     |         Ether-1                           Ether-2
 Appletalk

I have configured Telnet with host A as the gateway.  I can do the
following without problem:

1. Telnet from Mac to A, B, or C.

2. Telnet arbitrarily among the hosts A, B, C, and D.

3. FTP from D to Mac.

4. Telnet from Mac to A and then telnet from A to D.

BUT, when I try to telnet from Mac to D I get connected, I can login,
but the login hangs in the middle.  Looking on D shows that D thinks
there is a telent connection, login is complete, my shell is running,
waiting for input, but netstat -a shows 20-40 packets in the send
queue for Mac.

My default parameters for NCSA Telnet are

	retrans=20
	mtu=512
	maxseg=512
	rwin=512

I have played a little with changing retrans to no avail.  I am
especially confused because telnet from Mac to C works and ftp from D
to Mac works.

Anybody got any ideas?  Thanks in advance.

	Cory Myers

	cory%aaec1.uucp@dspvax.mit.edu

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 16:33:32 GMT
From:      zsu@NISC.SRI.COM (Zaw-Sing Su)
To:        comp.protocols.tcp-ip
Subject:   Re: What's a "fuzzball"?


No need to collect them.  Just go after that wizard.  He has
a jugful of these jargons!

Zaw-Sing

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 17:40:56 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts, DNS, sendmail.cf, YP ?

>first I want to explain my scenario: let's say I have some hundred
>lovely UNIX-Workstations (AIX, DomainOS, HP-UX, Ultrix, Unicos, 386/ix,
>etc.). They are all connected through a campus wide Ethernet and all
>speak TCP/IP. Then I have a mailserver (Sparc, SunOS) who has to do the
>following:
> - act as mail-gateway between SMTP and X.400
> - act as mailforwarder for all my workstation, so that they don't
>   have to know, where hey will find all their mail partners
> - act as connector to the Internet
> - act as Domain Name Server for a big part of my domain.
>Screening all my TCP/IP-implementations some questions arose:
>1.) Should /etc/hosts contain full qualified Domain Style Names or just
>    UNIX-nodenames? Some implementations need a valid nodename-entry
>    to set up the interface with ifconfig, some sendmail.cf need FQD to r
>    reach the hosts if they are not in the same domain. (I have a Cray
>    nearby in another domain).

/etc/hosts should contain the fqdn as the first name for any entry.  You
probably want to have the short form of the name as well for local hosts.

>2.) If I set up Domain Name Service I cannot provide short nicknames in
>    other domains, so hacking ip-numbers would be easier to use
>    telnet and ftp.

Not completely true.  You can define a list of domains to search in
/etc/resolv.conf or its equivalent.  These domains are appended to the
requested name.  Some implementations only do this for short (one part)
names (my preference!); others do it to any name.  This applies to
telnet, ftp, and the like; generally does not apply to SMTP, excluding
some hacks in sendmail.cf.

>    Some implementations do  not fall back to /etc/hosts if the
>    nameserver has no answer. Am I missing something?

There has been discussion on this in the past; this is probably a good
thing, since the DNS should have more accurate answers than the
/etc/hosts file.  A bad answer can be worse than no answer, especially
if you have an alternate query to try in the "no answer" case.

>3.) Some people here use Yellow Pages (YP). If I am right the
>    YP-host-maps are derived from /etc/hosts. So what if the YP-domain
>    and the DNS-domain are different?

If possible, I would try to avoid YP for host name resolution, or at least
make DNS take precedence.

>    Again the question: UNIX-nodenames or fully qualified DNS-
>    domainnames ?

Fqdn's, for sure.

>    What can I assume when they do a gethostbyname()? Will the answer
>    come from YP, DNS, /etc/hosts or have I to set up a separate table
>    for sendmail?

Gethostbyname will get answers from any/all of the above.  DNS should
take precedence over /etc/hosts; I forget where YP fits in, but I would
suggest installing a non-YP version of gethostbyname if you can.  Newer
versions of sendmail (with MX support) do not normally call the standard
gethostbyname, so they will strictly use the DNS.

>So the things seem to be complicate. I would like to give my users
>some useful and short informations to set up their machines:
>- if you want to use /etc/hosts only I'll give you a valid file,
>- if you want to use DNS do the following (...)
>- if you want to set up SMTP (no UUCP concerned here) I give you a
>  general sendmail.cf,
>    fill in your hostname
>    fill in your (sub-)domainname and that's it,
>- if you have YP running consider the following things (...)

That's much like what I try to do.  I direct people to use DNS
where possible; I let the groups with YP solve their own problems,
and tomorrow I'll work on a better sendmail.cf.....

Doug Nelson
Network Software Manager
Michigan State University

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 17:48:51 GMT
From:      mcsun!hp4nl!uvabick!matthew@uunet.uu.net  (Matthew Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   Wanted: how to uucp to a modem on a terminal server
Hello!  I have a modem (a Trailblazer) hooked up to a CS/100 terminal
server.  I would like to be able to use this for outgoing UUCP.  Has
anyone done this before?  If so, how?

Thanks in advance, 

Matthew Lewis
-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
31-20-52 51 220					1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands
UUCP:	  uunet!mcsun!hp4nl!uvabick!matthew
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 18:47:00 GMT
From:      ULTIMA@UNC.BITNET (Paul Jones  962-6501, 919)
To:        comp.protocols.tcp-ip
Subject:   Re:      anonymous ftp, and the dangers thereof

Once there was a goose that laid golden eggs. Unfortuantely the goose
also had to be fed and watched and cleaned up after. Even worse there
were foxes that might want to eat the goose, but we fooled them; we
killed it and ate it first.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 19:02:40 GMT
From:      chee13h@jetson.uh.edu
To:        comp.protocols.tcp-ip
Subject:   What is SLIP? Where do I get it??


	I am sure this must have been battered around. I am writing a
distributed application with the client-server principle. I can easily
implement this using sockets or somesuch over the ethernet. However, I
would also like to be able to use it over serial line possibly connected
with modems on both ends. Somebody mentioned that SLIP would be appropriate
to use. WHAT is SLIP and where do I get it? If this is a commercial
implementation, how much does it cost? What are the performance characteristics
one can expect using this??? 

   	Is this this software available as public domain? We have a
heterogenous environment of SUN, DG AViion, PS6000, DEC 3100 & 386sx machines.
I should be able to use SLIP across all these platforms.

	please email or post as appropriate...

ashok

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 90 21:15:51 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re:  What's a "fuzzball"?

I thought the Chernobyl packet was an ARP reply for some IP broadcast
address with the target hardware address (in the ARP part) set to the
hardware broadcast address...

BillW
-------

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 01:16:00 GMT
From:      HAGGAR@BNR.CA (Haggar  Alsaleh, H.)
To:        comp.protocols.tcp-ip
Subject:   Net. Mng. References.

Greetings
Could some one help me understand the process of interfacing the
Application Layer to the rest of the layers in Network
management or the Management process within a single
node (i.e how the Management request is passed/handled between the
layers of a single node), Is there a standard or protocol for the
different layers to pass management information.
I have been looking at the RFC with no answer.
References on the subject will be great.
Your help will be very much appreciated.

                                  Haggar@bnr.ca
                                  Haggar Alsaleh
                                  1150 E. Arapho Rd.
                                  Richardson, TX 75081.
                                  214 997-4806.

"I'm a free man, I speak for my self and no body else......".

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 02:49:51 GMT
From:      Mills@udel.edu
To:        comp.protocols.tcp-ip
Subject:   Re:  What's a "fuzzball"?

Bill,

No, you describe the TMI option in the Chernobyl packet. This option is
considered very dangerous, so a special decoder and Morris certificate
is required for its use. We do have library by than name on campus, but
I don't know if it stocks worms.

Okay, I'm gone.

Dave

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 02:54:39 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

Wait a darn minute here!  Marty and Dave are "not fighting".  Many readers
might mistake their discussion as some kind of "battle", but they both
are subscribing to the belief that "in vitro" testing is the best method
for "realizing" something we would all want to rely upon ("buy" is
another word...).

Marty is saying that it is now impossible for a vendor to use the excuse
that they cannot get on the Internet to test their products.  He is right.
Dave is now saying that it is impossible for vendors to complain
that there is no place for testing "really weird stuff" or even normal
stuff -- he's volunteered a place.  This is great news.  "Users" (those
who pay for "everything" (eventually)) will win because of these new
capabilities for "improving the breed".  

A round of applause for both of these approaches.  There might even be
more ways to skin this cat, but these two are'nt too shabby!

Dan
-------

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 03:13:04 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?


 You focus solely on network management software.  While that certainly
 is one of the essential areas of recent and continuing activity, the
 OpenLab is intended for any and all protocol interoperability testing.
 If a group has developed the Networked Widget Protocol and wants to
 conduct multi-vendor NWP tests, OpenLab is as available to them as it
 is to the loftier, more publicized standards efforts.

I'm just a parochial kind of person, is there anything other than network
management?  :-)

But really, It was just an example of an entire process that could
be put together.


 To the extent that your note indicates that there is little direct
 need for a general-purpose neutral territory, for interoperability
 testing, I can only assure you that the idea for OpenLab was born
 strictly of need.  I assume that your recent switch into the commercial
 sector will lead to your experiencing this issue increasingly.

Having worked both in and with the commercial sector for the past decade
vis a vis tcp/ip I've seen a number of interoperability labs come and
go with few successes, of course the question of what the metrics of success
should be is in itself an interesting discussion.  What is so
fascinating to me is the soft sell of a DEC facility as neutral territory,
tremendous marketing panache.  Move the mirrors a little, add some
additional smoke and I'll sware I'm yodeling in Switzerland again.

I'd be fascinated to know quantitative details of the use and successes of
your pet project; however, what might be considered is the public record
of what has happened of late in various areas like network management, serial
interoperability, directory, dns, etc... without the above.  Now add
a full-time neutral coordinator, ready to work with the various communities,from
small startups, to the researchers, to big dinosaurs, to users, and we might
catalyze the process.

Marty

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 03:17:01 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

Hi Dan,

Playing Solomon again?  One of us might not like the half that we get!

Marty
-------

 Wait a darn minute here!  Marty and Dave are "not fighting".  Many readers
 might mistake their discussion as some kind of "battle", but they both
 are subscribing to the belief that "in vitro" testing is the best method
 for "realizing" something we would all want to rely upon ("buy" is
 another word...).

 Marty is saying that it is now impossible for a vendor to use the excuse
 that they cannot get on the Internet to test their products.  He is right.
 Dave is now saying that it is impossible for vendors to complain
 that there is no place for testing "really weird stuff" or even normal
 stuff -- he's volunteered a place.  This is great news.  "Users" (those
 who pay for "everything" (eventually)) will win because of these new
 capabilities for "improving the breed".  

 A round of applause for both of these approaches.  There might even be
 more ways to skin this cat, but these two are'nt too shabby!

 Dan
 -------

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 13:54:00 GMT
From:      OWEN@DUCVAX.AUBURN.EDU (Larry Owen)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, and the dangers thereof

>>  I am not up on which versions of FTP are currently vulnerable but it
>>strikes me as quite irresponsible to use actual host names in an example.
>>If nothing else, you're going to get some people FTPing to it just to
>>see what the scoop is. (I just did to see if you really were using an
>>actual example.)
 
>I think you are quite wrong.  To be on the internet these days your
>system had better be secure.  Your login accounts had better have good
>passwords, your ftp had better be secure, etc.  It would extremely trivial
>to query every entry in /etc/hosts for ftp version information.
>If it is really a hole don't you think there are hacker's that have
>exploited it?
 > Would I be wrong to tell a co-worker that some idiot sysadmin at bozo.com
>has root wide open without a password (just an example).  My company is not on
>the internet.  We may be in the near future.  If this is to happen things
>will have to be *extremely* secure on the machine that connects.
>I have co-workers who don't really know what the internet is expressing
>concern about security in the face of the the possibility of connecting to
>it (from what they here on the news).
 
You're damn right you would be wrong, at least if you did so without
going to the trouble of finding out who was responsible for the machine
and letting him/her know about it first!  Lots of machines on the Internet
are managed by people for whom system management is not in their job
description or career path.  It's irresponsible to draw targets around
such systems and yell "have at it, boys!".

It should also be remembered that the machine doesn't belong to the
system manager.  You seem to be taking the attitude that the system
manager of an incompletely secured system gets what he/she deserves
when someone points out a weakness in their system to the network
community at large, and someone takes advantage of the information.
Maybe so (and maybe not), but it's the *users* of the system who
pay a large share of the price, and they are innocent bystanders.
Using a real-life example was irresponsible.

Larry Owen
Mgr., Network Support
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 14:08:00 GMT
From:      OWEN@DUCVAX.AUBURN.EDU (Larry Owen)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, and the dangers thereof

chrome@hscfsas1.harvard.edu (David C. Kovar) writes:
 
>>								     it
>>strikes me as quite irresponsible to use actual host names in an example.
 
He goes on to warn:
 
>>			     Worse still, there is a small chance,
>>very small given current laws, that you will be held responsible for
>>any break in caused by your post.

To which Bill Wisner replies:

>>Chill out, Dave. Ed used his *own machine* as an example. Really.
 
I had fired off a hard-edged rebuttal to an intervening message which
seemed to suggest that it was okay to point out weaknesses in specific
systems' security to the network at large.  Both I and the message I
was rebutting were operating without the knowledge provided by Bill
Wisner.  So, it *wasn't* irresponsible to point this out about his
own system, and my rebuttal would have a mellower tone if posted now.
The essence of the rebuttal stands, though.  It is more responsible
to take a wounded kitten to the vet than to throw it into a pen full
of hungry pit bulls.

Larry Owen
Mgr., Network Support
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 14:34:23 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

In article <9004200313.AA22741@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:

   ... Now add
   a full-time neutral coordinator, ready to work with the various communities,from
   small startups, to the researchers, to big dinosaurs, to users, and we might
   catalyze the process.

Ah, but who will pay the salary of this full-time coordinator?  You're not
going to find too many volunteers for the task.

sounds like real work (but interesting) to me.

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 14:49:48 GMT
From:      dcrocker@WRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there SNMP Certification Testing?

Marty's concern about OpenLab(sm)'s neutrality is quite natural, so that
it might be appropriate to explain a little more about the set-up that
we have:

Network System Lab's space is arranged so that OpenLab has its OWN
entrance from the building lobby.  There is a small interior lobby and
direct access to restrooms.  The OpenLab space will hold about 5-10
people and machines. 

All of this is separated from the rest of the NSL facility by a 
controlled-access door.  However, for larger activities, this door
can be unlocked and another door locked.  In this large-scale
configuration, an entire quadrant of NSL is isolated.  This space
is otherwise used for conference rooms.  In the fully-open
configuration, I believe it can hold about 50 people and machines
for testing.

A Digital security guard will sit in the small OpenLab lobby and will
check people in and out, but this has more to do with providing
safety for the hardware that comes and goes.  Participants will have
free access to OpenLab, the restrooms, and the outside world, without
having to be escorted, which tends to be required in most companies
these days.

Dave

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 15:33:32 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   seeking info on Acces Control List (ACL) mods to inetd

Has anyone hacked inetd to consult an Access Control List or other
security extensions, to control/audit what hosts/nets request
inetd services (r-utilities, ftp, ....)?
thanks
tom
  dunigan@msr.epm.ornl.gov

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 16:18:39 GMT
From:      jgd@csd4.csd.uwm.edu (John G Dobnick)
To:        comp.protocols.tcp-ip
Subject:   Re:  What's a "fuzzball"?

In article <9004190943.aa06426@huey.udel.edu>, Mills@udel.edu defines 
"chernobyl packet" and "christmas tree" packet.

Has anyone collected a glossary of these terms?  If so, is it available, and
if so, where?  [Shouldn't there be an RFC for this? :-) ]

Thank you,
-- 
John G Dobnick  (JGD2)
Computing Services Division @ University of Wisconsin - Milwaukee
INTERNET: jgd@csd4.csd.uwm.edu             ATTnet: (414) 229-5727
UUCP: uunet!uwm!csd4.csd.uwm.edu!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 17:44:00 GMT
From:      w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen)
To:        comp.protocols.tcp-ip
Subject:   SIMTEL20 services available to Govt & Govt contractors

[I realize this is not on the subject of tcp/ip but it *is*
the intended audience.]

Dear TCP/IP friends:

SIMTEL20's primary charter is to provide service as an email host
for U.S. Government (which includes military and other government
agencies) and contractors doing business with the U.S. Government
who do not have an Internet host of their own.

The hard part is finding these people who need an email host.  It's a
chicken-and-the-egg situation since we cannot send email to them to
offer our service.  I've been told that there are organizations out
there which need as many as 500 accounts for their people.  All we
have to do is find out who they are so we can contact them by phone.

We need your help in trying to locate these organizations.  Please pass
the word to anyone you think might be in need of our services.

For further information, please contact Elwood Baas at AV 258-1011 or
505-678-1011 or EBAAS@WSMR-SIMTEL20.ARMY.MIL.

Keith
--
Keith Petersen
Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74]
Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.mil  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 19:14:09 GMT
From:      spurgeon@ut-emx.UUCP (Charles Spurgeon)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Network reading list available

A new version of an annotated network reading list, the "Network
Manager's Reading List: TCP/IP, UNIX, and Ethernet," is available.
The list covers about 30 items and weighs in at roughly 8,500 words.

The list doesn't try to be comprehensive.  Instead, it was created to
provide a fairly complete description of some useful sources of
networking information.  Originally written for network managers at
the University of Texas, the list is being made more widely available
in the hopes that it can help others save some time looking up these
resources.

The only system I have access to that supports anonymous ftp is also
heavily used to support academic computing at the University of Texas.
Therefore, the following helpful folks have made the list available at
their sites:
------------------------------------------------------------------------
The list has been stored in text (txt) and PostScript (ps) format in
the Rice University SunSpot archives.  
Via anonymous FTP:
		Hostname : titan.rice.edu (128.42.1.30)
		Directory: sun-source
		Filename : nmread.{txt,ps}

Via electronic mail:
Archive Server Address: archive-server@rice.edu
Archive Server Command: send sun-source nmread.{txt,ps}
------------------------------------------------------------------------
The list is also available via anonymous FTP from:
		Hostname : vax.ftp.com (128.127.2.100)
		Directory: pub
		Filename : net-reading-list.{txt,ps}
------------------------------------------------------------------------

Here's the Introduction from the list:

      This is an annotated list of books and other  resources
      of  use to network managers who are using TCP/IP, UNIX,
      and Ethernet technologies.    These three  technologies
      share  the  same  major attribute: network managers can
      use them to build interoperable network systems  across
      a  wide  range  of  vendor  equipment.   This  list  is
      intended for campus network managers at the  University
      of  Texas at Austin, or anywhere that TCP/IP, UNIX, and
      Ethernet are used to provide computer communications.

      Each item in the list is annotated, and many items have
      introductory  material  quoted  to  help indicate their
      scope and organization.  Access  information  is  given
      for  each item, and prices are included when available.
      The prices listed here are culled  from  a  variety  of
      sources and should be used only as a rough guide.

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 19:22:33 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: anonymous ftp, and the dangers thereof

In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>... There are lessons to be learned, starting with the
>abolishment of /etc/passwd and user access to the encryption
>algorithm.

Ah yes, good old security-through-obscurity.  Where have we heard that
before?
-- 
If OSI is the answer, what on |     Henry Spencer at U of Toronto Zoology
Earth could be the question?? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 20:28:27 GMT
From:      kwang@infmx.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Difference between U.S. GOSIP and U.K. GOSIP

Hi ... there,

	I've just got U.K. GOSIP documents. Does anybody already know what
is difference between U.S. GOSIP and U.K. GOSIP for each layer ??
Please let me know. Thanx.

					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 20:41:49 GMT
From:      bryan@terminator.cc.umich.edu (Bryan Beecher)
To:        comp.protocols.tcp-ip
Subject:   Appending domain names

In article <9004201944.AA23924@ucbvax.Berkeley.EDU> 08071TCP@MSU.BITNET (Doug Nelson) writes:
>Not completely true.  You can define a list of domains to search in
>/etc/resolv.conf or its equivalent.  These domains are appended to the
>requested name.  Some implementations only do this for short (one part)
>names (my preference!); others do it to any name.  This applies to
>telnet, ftp, and the like; generally does not apply to SMTP, excluding
>some hacks in sendmail.cf.

I believe you can only list one domain in /etc/resolv.conf, and
only its subdomains will be searched.  For instance, if the domain
listed is a.b.c, then queries for name.a.b.c and then name.b.c will
be generated.  (The resolver won't generate a name.c query.)

You can define a list of domains in the environment variable
DOMAINPATH if you wish if you use the U-M resolver library.
Further, if 'name' has two or more dots in it, 'name' will be
sent to the nameserver first before name.a.b.c, etc. are tried.
(This eliminates a number of unnecessary queries.)

This library is part of our BIND 4.8.1 (which started out as
a vanilla 4.8.1, but now contains some bug fixes and enhancements
like DOMAINPATH).  It's available on terminator.cc.umich.edu
in ~ftp/unix/bind4.8.1.tar.Z if anyone is interested.
--
Bryan Beecher, U-M Information Technology Division  (+1 313 747 4050)
Domain:	bryan@terminator.cc.umich.edu  Path: mailrus!terminator!bryan

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 90 23:49:08 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: anonymous ftp, and the dangers thereof

In article <1990Apr20.192233.4092@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>>... There are lessons to be learned, starting with the
>>abolishment of /etc/passwd and user access to the encryption
>>algorithm.
>
>Ah yes, good old security-through-obscurity.  Where have we heard that
>before?

No.  We aren't talking about hiding passwords in a secret file.  Any
file, once known, can be gotten at.  We are talking about hiding the
password where only the kernel can get at them.  Granted, a program
that does absolute disk reads can get at the passwords; but such a
program (1) can't be run under FTP (2) can only be run by a privileged
user (and hence the system is already violated).

We are talking about setreuid() not requiring any privileges, but
taking a password as an argument.  We are talking about no "setuid"
programs; in its place are new unprivileged system calls which make
the necessary checks.

In other words, we're talking about making it harder for the system to
be compromised simply by poor file protections!

Unix purists argue that this "adds a lot of junk to the kernel" and
interferes with the beauty and elegance of Unix.  I hate to break it
to them, but the Unix kernel hasn't been "small and beautiful" since
PDP-11 days.
 _____   | ____ ___|___   /__   Mark Crispin           Atheist & Proud
 _|_|_  -|- ||   __|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_|  |\-++-  |===|  /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--  /| ||||  |___|    /\    USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /  \   +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__|  /   \  /    \  mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 90 00:50:31 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: anonymous ftp, and the dangers thereof

> No.  We aren't talking about hiding passwords in a secret file.  Any
> file, once known, can be gotten at.  We are talking about hiding the
> password where only the kernel can get at them.

Where, pray tell? Are you suggesting that some part of the disk be
unavailable through /dev/dsk/*? That would make backups kind of hard.
What happens if your password structure gets damaged?

> Granted, a program
> that does absolute disk reads can get at the passwords; but such a
> program (1) can't be run under FTP

ftp machine:/dev/dsk/c0d0s0 machine/rootdev

> (2) can only be run by a privileged
> user (and hence the system is already violated).

Just sticking the passwords in a root-read-only file would do just as
well...

Like /etc/shadow.
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180.      <peter@ficc.uu.net>
/      \  'U`  Have you hugged your wolf today?  <peter@sugar.hackercorp.com>
\_.--._/
      v        Disclaimer: People have opinions, organisations have policy.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 90 01:38:26 GMT
From:      djh@osc.edu (David Heisterberg)
To:        alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: anonymous ftp, and the dangers thereof

In article <1990Apr20.192233.4092@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
> >... There are lessons to be learned, starting with the
> >abolishment of /etc/passwd and user access to the encryption
> >algorithm.
> 
> Ah yes, good old security-through-obscurity.  Where have we heard that
> before?

I think that's hardly a fair criticism.  I don't see how the original
article could be read as advocating security-through-obscurity.  What's
unreasonable about hiding sensitive information in addition to doing a
good job of providing real security?  Of course, if you *rely* on hiding
the password file then I agree you're in trouble.

It's like taking vitamins.  Maybe you don't really need to, but doing
so won't hurt, and as long as it's inexpensive, why not?  Just don't
delude yourself into thinking that vitamins, Ding-Dongs, and taco sauce
makes for a balanced diet.
-- 
David J. Heisterberg		djh@osc.edu		And you all know
The Ohio Supercomputer Center	djh@ohstpy.bitnet	security Is mortals'
Columbus, Ohio			ohstpy::djh		chiefest enemy.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 90 22:45:22 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   anonymous ftp, and the dangers thereof


From: ogicse!blake!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
>It worked pretty well.  Most Tenex/TOPS-20 sites had warm fuzzy
>feelings about allowing ANONYMOUS and never had any security problems
>because of it.  There are lessons to be learned, starting with the
>abolishment of /etc/passwd and user access to the encryption
>algorithm.

...and of course those were different times...unix sites used to have
warmer, fuzzier days also.

Although many Unix systems have adopted shadow passwords (which does
exactly what you describe, only a super-user can read the encryptions)
I am not entirely convinced this has really made things more secure,
just shifted the target a bit, a band-aid hiding a more fundamental,
general problem.

What's really needed is a more secure encryption algorithm so you can,
with great confidence, parade the encryptions out in public with
little worry, even if some of those encrypt dictionary words etc
(although avoiding those by other means is always a good idea, that
usually belongs at the password setting level.)

This current situation (shadow passwd) relies on the security of the
/etc/passwd file and admits that anyone getting a hold of it, even
though it only contains encryptions, has compromised security (if not,
why hide it?)

We all know that many silly administrative or programming errors, on
every OS (not just Unix) I know of that ever lets a program get at a
file which a user can't w/o the program, have let a user one time or
another at least list a file which was unintended (typically because a
program which uses read-only access isn't checked as carefully.)

Or someone (with privs) put a file to paper and lost control of that
paper, or a backup tape, etc.

And, I would continue, the encryption algorithms *should* be readily
accessible. That's just security by obscurity, so, every site with a
source license who isn't careful about someone getting a listing of
that one algorithm has compromised every system in the world's
security? Hogwash, assume the algorithm can be known! Security by
obscurity is false security.

Something I always thought would help would be if when, a system is
installed, the admin would be asked to enter a string which perturbed
the password encryption algorithm on that one machine (or cluster, if
desired.) This could probably be reasonably secured and no one ever
need know that string again if it's done right (the key code could be
carried, encrypted, through system software upgrades etc.)

That would at least mean that running the encryption algorithm on my
site against your password file would be useless unless I could first
guess the perturbation string. So you'd have to do your cracking using
my system, something which I assume would be harder than taking the
file away and using your own system, more noticeable etc.

BTW, Tops-20 was *AWFUL* in this regard, any priv'd person could list
the CLEARTEXT password of any account, or all of them (there were
standard sys utilities designed to just dump out all the directories
and passwords for an admin, in line printer format! I forget the name
but I suspect folks remember it.) So passwords were always popping up
on operator's or admins terminals etc. Maybe this was changed in 6.0,
but that was long after the whole OS was decommissioned, I hope we're
not talking about that stage in its life. As far as I can tell that
was *prompted* by Unix's practice, not their own doing.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 90 08:29:13 GMT
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, and the dangers thereof

> In article <1990Apr20.192233.4092@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
> >In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
> >>... There are lessons to be learned, starting with the
> >>abolishment of /etc/passwd and user access to the encryption
> >>algorithm.
> 
> In other words, we're talking about making it harder for the system to
> be compromised simply by poor file protections!
 
	my curiosity is aroused by exactly what this all has to do
	with IP/TCP (or TP4/3/2/1, ad nauseum)... 

> Unix purists argue that this "adds a lot of junk to the kernel" and
> interferes with the beauty and elegance of Unix.  I hate to break it
> to them, but the Unix kernel hasn't been "small and beautiful" since
> PDP-11 days.

	pdp-11s are STILL beautiful - just exclude the X-windows crud and
	they can do pretty much everything else (haven't gotten around to
	NFS yet).

	'course THAT has as much to do with TCP-IP as the original posting. :-)

	perhaps time to move this discourse to another group?  tcp-ip does
	tend to be a "common meeting point" for a lot of off-line discussions.

	Steven M. Schultz
	sms@wlv.imsd.contel.com

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Apr 90 08:17:43 PDT
From:      davy@itstd.sri.com
To:        tcp-ip@nic.ddn.mil
Subject:   Modems for SLIP

Here's a few questions for those of you running SLIP over cross-country
and international (between Europe and the U.S.) dial-up links with UNIX
systems.

1. What modems are you using (brand name, model number, etc.)?  Are you
   happy with them?  Why or why not?

2. What SLIP software are you using (Toronto Sun SLIP, Van Jacobson's
   compressed SLIP, etc.)?

3. What are you dialing into (an Annex box or other terminal server, a
   Sun server, etc.)?

Basically, we're going to be doing some dial-up SLIP stuff to some of
our sites around the country and in Europe soon, and I want to find out
what other people are using, in order to pick the stuff that's going
to work best.

Currently I'm leaning toward Telebit modems and Van Jacobson's
compressed SLIP, with some home-grown dial-up SLIP software, but I'm
willing to be convinced otherwise.

Please respond via mail to me to keep the traffic on this list to a
minimum.  I will summarize to the list.

Dave Curry
davy@itstd.sri.com
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Apr 90 11:17:27 pdt
From:      Walter Underwood <wunder@hp-ses.sde.hp.com>
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: seeking info on Acces Control List (ACL) mods to inetd
   Has anyone hacked inetd to consult an Access Control List or other
   security extensions, ...

Yes.  HP-UX has had this extension for several years.  We use the
file /usr/adm/inetd.sec.  I've appended a sample to this message.
"HP-Internet" is defined in /etc/networks (net 15).

wunder

--------
# Inetd security
# Don't allow more than MAXNUM simultaneous connections

MAXNUM 200

# For most services, allow connections from the HP internet
# only.  We must not allow ftp access from non-HP hosts, since
# some HP sensitive information may be present in the anonymous
# ftp area on this machine.  Finger and talk should be safe.

tftp    allow   15.0.8.9 15.255.152.1 15.13.32.1 15.13.32.22 \
		15.0.8.8 15.255.8.34  15.13.152.34 15.1.80.45 \
		15.254.32.2
smtp	allow	* deny 15.0.106.42 15.0.104.167
login	allow	HP-Internet
shell	allow	HP-Internet
exec	allow	HP-Internet
#                           cisco      ind-milnet
telnet	allow	HP-Internet 192.31.7.* 26.1.0.128
finger	allow	HP-Internet
quote	allow	HP-Internet
ntalk	allow	HP-Internet
stock	allow	HP-Internet
xtrek	allow	HP-Internet
uupath	allow	HP-Internet
repo	allow	HP-Internet
repodbg	allow	HP-Internet
#                           cisco
ftp	allow	HP-Internet 192.31.7.* 
#			    ind classC
install	allow	HP-Internet 192.6.70.* 
#                                  hpisqiz
ninstall	allow	127.* 15.* 192.6.143.*
mountd	allow	15.13.32.* 15.13.158.* 15.13.152.*
spc allow hp-ses hpsdeb hpsdel hpsdesis hpsesa indium main sde-leaf main sde-leaf hpsdeb hpsdel hpsdesis indium hpsesa hp-ses argon
mserve allow hp-ses hpsdeb hpsdel hpsesa indium main sde-leaf titanium main sde-leaf hpsdeb hpsdel hpsdesis indium hpsesa hp-ses argon




-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Apr 90 15:24:22 -0500
From:      "Craig A. Finseth" <fin@unet.unet.umn.edu>
To:        bzs@world.std.com
Cc:        ogicse!blake!Tomobiki-Cho!mrc@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   anonymous ftp, and the dangers thereof
It might be time for the discussion on this thread to take a step back
and review what the whole password scheme is about.


The basic idea is for there to be a character string that the rightful
user and no one else knows.  This string is sufficient to identify the
user to the system.


Problem 1 is that the system must retain knowledge of this string in
order to perform the verification.

Problem 2 is that attackers would like to obtain access to the system
by identifying the character string.

(This message will omit discussion of non-password and eavesdropping
attacks.)

Problem 1 is addressed by any non-volatile storage method.

Problem 2 is addressed by an array of solutions.

First, one must recognize that 100% protection is guaranteed.  If my
password is "%$gh&*2", there is a small but non-zero probability that
an attacker will use that string as its first guess.  No
password-based protection system can guard against this possibility.
The solutions, then, involve decreasing the probability that an attack
will succeed.

Second, the password is encrypted using a one-way function and only
the encrypted version is retained.  The likelihood of a different
character string encrypting to the same encrypted version is assumed
(or proven, whatever) to be sufficient small that it need not be
further considered.

(Encryption also has the advantage that inadvertent disclosures of the
database are not directly useful.  One must both have a disclosure
*and* it must be to an attacker for the disclosure to matter.
Encryption reduces the number of attackers by raising the effort
required to attack.)

Third, one could change the encryption algorithm.  However, the
general experience with "homebrew" encryption systems is that most are
not very good.  Hence, the community has chosen to stick with a
publicly-known, well-tested method.

Fourth, the method chosen by the community has proven (to my
knowledge) to be proof against inversion.  The attacks that have
succeded have been of the "try lots of likely possibilities and see if
any work" basis.  The defense against this method has several parts:

The first part is to hide the encrypted text, thus making all accesses
be controlled.  (This also reduces the number of disclosures.)

The next part is to slow the rate of attacks and to log all failed
attacks.

The final part is to reduce the probability that a real password is a
likely guess.  The best place to do this is to have the "passwd"
program reject "obvious" passwords (this can be done on binary-nly
systems).


Example:

Let's say that you are a manager of a local area network with 100
systems.  You have installed a modified passwd program that rejects
the "most obvious" ten million or so passwords (there are about five
billion 6 character passwords).  You also have logging software that
has an alarm set if more than 5 failed attempts happen per system per
day.  We will also assume that the attacker has full knowledge of your
system.

An attacker can have 500 "free" attempts per day.  Any more attempts
will trigger an alarm.  At that point, you can monitor the account
under attack more closely and take appropriate action (have the user
chagne passwords often, trace attacks, etc.)

Even if the attacker has some knowledge of the person being attacked,
the "most obvious" passwords have been excluded.  Thus, the attacker
will have to try a large number of attacks (say, one million) before
they might succeed.

Why such a large number?  Well, it isn't my wife's name (names are too
obvious) and it isn't a small variation (e.g., a name followed by a
special character), so it must be a name with two or more variations.
If there are, say, 100 names and each variation can be made 100 ways,
this leads to:

	100 names x 100^2 variations = 1 million tries

On average, the attack will succeed after 500,000 tries.  500,000
tries at 500 per day means that, on average, an attack will take about
3 years, assuming no slips and no password changes.  Whether this is
reasonable is up to each system administrator to decide.


Note, however, how the encryption, the hiding of encrypted versions,
the rejection of obvious passwords, and the logging all interact to
increase the security.  If any of those factors were not performed or
relaxed, the security of the system as a whole would be compromised.

In conclusion, everyone who contributed to this discussion is right.
Each of the pieces is necessary.  However, only when taken together
are they sufficient.

Craig A. Finseth			fin@unet.umn.edu [CAF13]
University Networking Services		+1 612 624 3375 desk
University of Minnesota			+1 612 626 1002 FAX
130 Lind Hall, 207 Church St SE, Minneapolis MN 55455-0134, U.S.A.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Apr 90 14:34:52 -0400
From:      bzs@world.std.com (Barry Shein)
To:        crdgw1!sixhub!davidsen@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   anonymous ftp, and the dangers thereof

From: crdgw1!sixhub!davidsen@uunet.uu.net  (Wm E. Davidsen Jr)
>  I don't know that I have any objections to shadow password. WHy give
>the show away? It's like having L.sys or Systems world readable. I
>accept that I can't keep the encryption a secret, so why give the
>encrypted passwords away. I don't see what this has to do with
>security-through-obscurity here.

Actually, it's not at all like L.sys, and the difference is extremely
important to the discussion.

L.sys holds passwords which must be presented in cleartext (they're
used for automatic login to other systems).

The password file only has to match encryptions.

Hence, at best you must have a reversible encryption for L.sys so you
can get back the cleartext, which is obviously not worth doing (well,
perhaps some scheme could be proposed, but it's not easy.)

A password file works fine with one-way trapdoor algorithms that
basically can't be reversed (ok, let's not get into that, but are very
difficult to reverse IF a good password is chosen in the first place
so simple list testing is thwarted.)

The difference between these two situations is all the difference in
the world. I'm not picking nits here.

The security of L.sys files is that they hold passwords which should
only get access to UUCP transfers, for most systems only mail and/or
news, not terribly unlike the completely unprotected SMTP and NNTP
ports on TCP/IP networks. Of course, that also has to be properly
managed, but at that level passwords are not as critical a line of
defense as, say, ordinary user passwords, they're passwords to
(supposedly) castrated accounts (yes, yes, there have been holes, but
the same can be said for SMTP ports which have no passwords.)

Anyhow, the point is, it's not enough to just say it's all the same,
the whole thing begs careful thought. Although in theory a $1,000
dollar lock will protect better than a $100 dollar lock it doesn't
make a lot of sense if you're careful to only put $100 value behind
the lock. &c. L.sys needs only the $100 lock if properly administered,
the password file needs more, including the ability to feel secure
even if the file itself gets away from you.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 09:25:20 GMT
From:      mcsun!hp4nl!ruuinf!praxis!edwin@uunet.uu.net  (Edwin Kremer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network reading list available
In article <28624@ut-emx.UUCP> spurgeon@ut-emx.UUCP (Charles Spurgeon) writes:

   | A new version of an annotated network reading list, the "Network
   | Manager's Reading List: TCP/IP, UNIX, and Ethernet," is available.
   | The list covers about 30 items and weighs in at roughly 8,500 words.

European sites might prefer to get this very useful document from
the east side of the Atlantic. Here are the details:

The list has been stored in text (txt) and PostScript (ps) format in the
Dept. of Computer Science, Utrecht University, the Netherlands archives.  
Via anonymous FTP:
		Hostname : sol.cs.ruu.nl [131.211.80.5]
		Directory: pub/DOC
		Filename : nmread.{txt,ps}.Z

Via electronic mail:
	Mail-Server Address:	mail-server@cs.ruu.nl
	Mail-Server Commands:	send DOC/nmread.txt.Z
				send DOC/nmread.ps.Z
				end



			good luck,
						--[ Edwin ]--
--
Edwin Kremer (SysAdm), Dept. of Computer Science, Utrecht University
Padualaan 14,   P.O. Box 80.089,  3508 TB  Utrecht,  The Netherlands
Telephone: +31-30-534104  | UUCP: ...!uunet!mcsun!hp4nl!ruuinf!edwin
Telefax  : +31-30-513791  | Email: edwin@cs.ruu.nl    [131.211.80.5]
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 17:27:11 GMT
From:      voder!nsc!nsc.nsc.com!balaji@ucbvax.Berkeley.EDU  (Balaji Pitchaikani)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP-IP & X.25 co-existence

Hi,
      This information is for a friend of mine. He has a Dual Systems Corp.'s
VME Based UNIX System. He wants to add a X.25 Card with TCP-IP running on it. 
He has the following questions about their co-existence.

    1. All cards w/software donot support co-existence.Is this true?
    2. What should he do to have X.25 and TCP-IP co-existence.
    3. ARE ANY CARDS AVAILABLE With Software for VME Based (Dual Corp.)
	    systems which support X.25 and TCP-IP.
    
You may e-mail me the responses or post it to the net as others may also
be interested to know about it.

Thanks in advance,

balaji
(balaji@nsc.nsc.com)

+---------------------------------------------------------------------------+
|   My opinions may have changed, but not the fact that I am right.         |
|                                                                           |
|                       email : balaji@nsc.nsc.com.UUCP                     |
+---------------------------------------------------------------------------+
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 17:47:18 GMT
From:      ogicse!unicorn!blake!Tomobiki-Cho!mrc@uunet.uu.net  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof

In a former life, I was a TOPS-20 software support guy.  The last
TOPS-20 system I supported never suffered a major security breach, in
spite of being (to this day) a very visible and tempting target.  I
can not reveal specifics of the measures taken.  Very little depends
upon those measures being secret ("security by obscurity"); it is
however just a few more firewalls in the way of the potential cracker.
Most of these measures are totally invisible to a user; they don't get
in the way of his work.

To this day, that system has open anonymous FTP to any world-readable
file.  I find the Unix anonymous mechanism, where neither I nor my
contacts elsewhere can exchange files without going to effort to
install on ~ftp, to be abominable.  I can't tell one of my research
collaborators, "ftp /a/mrc/foo.c periodically to get my latest version
of foo."

In article <9004212245.AA05424@world.std.com> bzs@world.std.com (Barry Shein) writes:
>BTW, Tops-20 was *AWFUL* in this regard, any priv'd person could list
>the CLEARTEXT password of any account, or all of them (there were
>standard sys utilities designed to just dump out all the directories
>and passwords for an admin, in line printer format! I forget the name
>but I suspect folks remember it.)

ULIST, a worthless program that most systems deleted immediately!

> So passwords were always popping up
>on operator's or admins terminals etc. Maybe this was changed in 6.0,
>but that was long after the whole OS was decommissioned, I hope we're
>not talking about that stage in its life. As far as I can tell that
>was *prompted* by Unix's practice, not their own doing.

For the record, password encryption was done in Tenex 1.34, a decade
before Unix made it out to the general world.  DEC did not adopt it in
their first versions of TOPS-20; I suspect laziness but I heard a
claim that "it was so administrators could make sure users picked good
passwords."  In those days *all* DEC OS's had plaintext passwords.
Most network TOPS-20 sites implemented Tenex's encryption in their
systems long before DEC got around to it.

The point was that passwords, in any form, were well-hidden.  Only the
privileged system calls "get directory parameters" and "absolute disk
read" could read passwords.  Partially because of stupid programs like
ULIST, it was recognized that this wasn't enough; they must be
encrypted as well.  However, even as plaintext, passwords were
compromised *only* if a bad guy got access to a privileged user's
output.

There is a dangerous attitude that security is the result of a "quick
fix" instead of a combination of things.  Part of this attitude is
that you should cripple anonymous, because if public files get out,
then you've lost security.  Why are these files public?  Why should J.
Random User be able to read a password, even encrypted?  Why should J.
Random User be able to do absolute disk reads via /dev/rmumble?

Why is tftp "dangerous"?  tftp is a network protocol.  The "danger" of
tftp is that it may let your system reveal what it will already reveal
to anyone who gets logged in.
 _____   | ____ ___|___   /__   Mark Crispin           Atheist & Proud
 _|_|_  -|- ||   __|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_|  |\-++-  |===|  /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--  /| ||||  |___|    /\    USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /  \   +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__|  /   \  /    \  mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 17:52:41 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!ut-emx!walt.cc.utexas.edu!pmaniac@ucsd.edu  (Noah Friedman)
To:        tcp-ip@nic.ddn.mil
Subject:   abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>... There are lessons to be learned, starting with the
>abolishment of /etc/passwd and user access to the encryption
>algorithm.

I don't know that this is necessary. While it's possible that someone
already has worked out a way to reverse DES, having access to
/etc/passwd is quite useful. A number of my programs use information
in this database, including the password field, so that other users
can use their own passwords for various options while running my
programs. 

If DES is breakable, then a new algorithm needs to be implemented. And
users should be encouraged to choose good passwords, otherwise it
doesn't matter what encryption mechanism is used.

It's probably already been mentioned, but there is no good way to hide
the encryption algorithm. Even if it's hardcoded into the kernal, it
can always be disassembled.

Noah Friedman
pmaniac@ccwf.cc.utexas.edu
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 18:10:53 GMT
From:      clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!utzoo!henry@uunet.uu.net  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <6721@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>>>... There are lessons to be learned, starting with the
>>>abolishment of /etc/passwd and user access to the encryption
>>>algorithm.
>>
>>Ah yes, good old security-through-obscurity.  Where have we heard that
>>before?
>
>No.  We aren't talking about hiding passwords in a secret file...

You do appear to be talking about keeping the encryption algorithm secret,
though, since that's the only way to "abolish user access" to it.

I'm in favor of shadow password files, which seem a reasonable approach.
Someone who can't be bothered protecting a shadow password file probably
can't be bothered protecting his disk devices either, so being fancier
is pointless.  And trying to keep the users from learning how encryption
works is just silly.
-- 
If OSI is the answer, what on |     Henry Spencer at U of Toronto Zoology
Earth could be the question?? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Apr 90 06:25:48 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        pilchuck!amc-gw!ttrnds!morpho!news@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP Window Question
It is the transmitting station's responsibility to re-schedule transmission.
Too many vendors/implementors tend to forget that the transmitting station is
the active component and fail to implement robust transmission strategies
regardless of the communication protocol.

Merton
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 19:44:24 GMT
From:      popvax!kovar@husc6.harvard.edu  (David C. Kovar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Apr19.205930.15589@caen.engin.umich.edu> fozzy@caen.engin.umich.edu (Eric Wines) writes:
>In article <2616@husc6.harvard.edu> chrome@hscfsas1.UUCP (David C. Kovar) writes:
>>  I am not up on which versions of FTP are currently vulnerable but it
>>strikes me as quite irresponsible to use actual host names in an example.
>>If nothing else, you're going to get some people FTPing to it just to
>>see what the scoop is. (I just did to see if you really were using an
>>actual example.)
>>
>
>I think you are quite wrong.  To be on the internet these days your 
>system had better be secure.  Your login accounts had better have good
>passwords, your ftp had better be secure, etc.  It would extremely trivial
>to query every entry in /etc/hosts for ftp version information.
>If it is really a hole don't you think there are hacker's that have
>exploited it?
>  Would I be wrong to tell a co-worker that some idiot sysadmin at bozo.com
>has root wide open without a password (just an example).

  So, if in the course of my normal, legal wanderings around the Internet
I find that your machine has a security flaw I should immediately post
to alt.security saying "Machine X has a security flaw Y and this is how
you exploit it?" I sincerely hope that this is not what you mean. 

  Yes, you should keep your machine as secure as possible if you're going
to attached yourself to a public network. I've no problems at all with
that. But if you discover a hole in my system and tell everyone else before
you tell me about it, I am going to be quite upset. And, if breaking into
my system is illegal, and you are party to an illegal act by passing
on that information, then you've also just broken the law.

 

-David C. Kovar
	Consultant				ARPA: kovar@popvax.harvard.edu
	Eclectic Associates			BITNET: corwin@harvarda.bitnet
	Ma Bell: 617-643-3373			MacNET: DKovar

         "It is easier to get forgiveness than permission."
[All opinions expressed are my own. Noone else assumes responsibility for me.]
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 20:24:12 GMT
From:      tiamat!chromc!dynasys!fedeva!mitch@uunet.uu.net  (Mitch Wood)
To:        tcp-ip@nic.ddn.mil
Subject:   LoNeed Local Bridge w/SNMP

Does anyone have a suggestion for a Local Bridge with SNMP support?

thanx in advance
Mitch Wood`
-- 
+---------------------------------------------------+----------------------+
! Mitch Wood @ FEDERAL EXPRESS Memphis, TN          #  "Ok you guys, quit  !
![..!hplabs!csun,..!mit-eddie!premise]!fedeva!mitch # clowning around and..!
+---------------------------------------------------+----------------------+
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Apr 90 10:10:00 -0700
From:      "Philip Almquist" <almquist@jessica.Stanford.EDU>
To:        pilchuck!amc-gw!ttrnds!morpho!news@uunet.uu.net (John Timlick)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP Window Question
Tim,

re: what happens after the TCP window goes to zero:
> So the $64K question is:  Is the receiving station supposed to send
> a message that says my window is now open or is the sender just supposed
> to wait a while and try again?  The analyzer shows that both sides just
> sit and wait until one side or the other eventually times out.

	The answer is "both". the receiver is supposed to send an ACK
when the window opens.  Since the ACK might be lost, the sender is
supposed to retry occasionally.  Neither side is supposed to time out
the connection unless the application has requested that it do so.  You
should point both vendors at RFC1122, where this is discussed at some
length.

						Philip
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 90 23:26:21 GMT
From:      pilchuck!amc-gw!ttrnds!morpho!news@uunet.uu.net  (John Timlick)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Window Question

Hello, World!

We have a tcp/ip problem when transferring files between two vendors
equipment.  We have a protocol analyzer which is on the network capturing all
packets between the two stations.  

The Problem is This:  When the window size on the receiving station goes
to 0, the sender stops sending.  This sounds reasonable and I understand
that is used as a method of flow control.  However, the window is never
opened up again so that file transfer can continue!  

So the $64K question is:  Is the receiving station supposed to send
a message that says my window is now open or is the sender just supposed
to wait a while and try again?  The analyzer shows that both sides just
sit and wait until one side or the other eventually times out.

I have talked to the tech support people at both vendors who say their
software is working correctly, and maybe it is, but we still have
situations where we cannot transfer files between these two systems.

Any help would be greatly appreciated.


John Timlick
...amc-gw!morpho!jt
(206)593-8015
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Apr 90 11:12:28 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        jt@morpho.uucp
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: TCP/IP Window Question

John:

    The sending TCP is required to periodically probe the receiver to
see if the receiver has opened its window.  Here's the relevant text
from RFC 1122.  Inform your vendors that reading is a required skill
in networking.


     4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42

	Probing of zero (offered) windows MUST be supported.

	A TCP MAY keep its offered receive window closed
	indefinitely.  As long as the receiving TCP continues to
	send acknowledgments in response to the probe segments, the
	sending TCP MUST allow the connection to stay open.

	DISCUSSION:
	     It is extremely important to remember that ACK
	     (acknowledgment) segments that contain no data are not
	     reliably transmitted by TCP.  If zero window probing is
	     not supported, a connection may hang forever when an
	     ACK segment that re-opens the window is lost.

	     The delay in opening a zero window generally occurs
	     when the receiving application stops taking data from
	     its TCP.  For example, consider a printer daemon
	     application, stopped because the printer ran out of
	     paper.

	The transmitting host SHOULD send the first zero-window
	probe when a zero window has existed for the retransmission
	timeout period (see Section 4.2.2.15), and SHOULD increase
	exponentially the interval between successive probes.

	DISCUSSION:
	     This procedure minimizes delay if the zero-window
	     condition is due to a lost ACK segment containing a
	     window-opening update.  Exponential backoff is
	     recommended, possibly with some maximum interval not
	     specified here.  This procedure is similar to that of
	     the retransmission algorithm, and it may be possible to
	     combine the two procedures in the implementation.


Craig
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 05:18:37 GMT
From:      haven!adm!smoke!w8sdz@ames.arc.nasa.gov  (Keith Petersen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
It seems to me that there is a simple solution to the problem of
anonymous ftp users being able to download /etc/passwd.  Hard code
a restriction into ftpd against being able to transfer any files named
"passwd" whether or not there was a path name included.

Keith

-- 
Keith Petersen
Maintainer of SIMTEL20's MSDOS, MISC, & CP/M archives [IP address 26.2.0.74]
Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.mil  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 07:04:39 GMT
From:      mcsun!hp4nl!nikhefk!henks@uunet.uu.net  (Henk Schouten)
To:        tcp-ip@nic.ddn.mil
Subject:   question about caching in UDP based RPC

hello out there,

I have a question about the use of caching in UDP based RPC. We seem to
have a problem here with an ever growing cache, eating up all memory.

What is the matter? I have builded a client-server application using UDP
based RPC. First I didn't use any caching at all, but when the machine
got heavy loaded retransmissions were generated and remote procedures
were executed more than once. Since I only have access to the SUN
Network Programming documentation, I hadn't found any pointer to the
cache mechanism.  So, originally I planned to build a cache myself and
started to look for a unique identifier for RPC messages.

Fortuneatly we have a source license, so I started to look for such
identifier when I found out that there exists support for caching in
the standard RPC package. But it sure is badly documented... Or was it
ment as a undocumented feature?

So, what is happening now? I enabled caching using svcudp_enablecache(),
specified a cache size of 4096. My opinion about caching is that whenever
an entry has to be added to the cache a check is needed to see if there
is still enough room. If not, the oldest entry should be removed in favor
for the new one. But, such thing does not happen. When the check points
out that the cache is full, new space is allocated instead.

At some moment there isn't enough core anymore and messages like:

	cache_set: could not allocate new rpc_buffer
	cache_set: victim alloc failed

are written on stderr. This is why I am quite sure about whether it is
the cache that is eating up memory.

I did not find any location where the deallocation takes place. It seems
to me that this might be the bug I was looking for. But it would sure
supprise me if it really is in the RPC package and not in my code. Or am
I using the caching facility in the wrong way? Anyone who can tell?

My code looks like this:

	:
	:

        if ((svcp = svcudp_create(RPC_ANYSOCK)) == NULL)
                fatal("main: svcudp_create");

        if (!svcudp_enablecache(svcp, (unsigned long) 4096))
                fatal("main: svcudp_enablecache");

        pmap_unset(MODEMPROG, MODEMVERS);
        if (!svc_register(svcp, MODEMPROG, MODEMVERS, svc_dispatch,
                                                                IPPROTO_UDP))
                fatal("main: svc_register");

        alarm(60);
        do
        {
                rfds = svc_fds;
                switch (select(32, &rfds, NULL, NULL, NULL))
                {
                case -1:
                        if (errno != EINTR)
                                fatal("main: select");

                        timeout = alarm(0);
                        mas_control();
                        alarm(timeout ? timeout : 60);
                        break;
                case 0:
                        break;
                default:
                        timeout = alarm(0);
                        svc_getreq(rfds);
                        alarm(timeout ? timeout : 60);
                        break;
                }
        }
        while (g.status != TERMINATE || g.users);

        printlog(LOG_INFO, "process exited normally");
        exit(0);
}

void    svc_dispatch(rqstp, svcp)
struct svc_req  *rqstp;
SVCXPRT         *svcp;
{
        ACCOUNT         account;
        CREDIT          credit;
        USER            *LookupUserByName(), *LookupUserByUid();
        long            offset;
        struct passwd   *pwd;
        int             uid;
        USER            user, *userp;
        extern bool_t   xdr_ACCOUNT();
        extern bool_t   xdr_CREDIT();
        extern bool_t   xdr_USER();

        switch (rqstp->rq_proc)
        {
        case NULLPROC:
                printlog(LOG_DEBUG, "NULLPROC");

                if (!svc_sendreply(svcp, xdr_void, 0))
                        fatal("svc_dispatch: svc_sendreply");
                break;
        case GETUSERBYNAME:
                if (!svc_getargs(svcp, xdr_USER, &user))
                        fatal("svc_dispatch: svc_getargs");

                printlog(LOG_DEBUG, "GETUSERBYNAME for %s", user.name);

                if ((userp = LookupUserByName(user.name)) == (USER *) NULL)
                {
                        /* user is not in user queue */
                        userp = &user;
                        if ((pwd = getpwnam(user.name)) != NULL)
                        {
                                userp->uid = pwd->pw_uid;
                                ReadUserInfo(userp);
                        }
                        else
                                userp->status = UNKNOWN;
                }

                /* determine time before we can call back */
                if (userp->status == ACCEPTED)
                {
                        if (g.max_busy == (USER *) NULL)
                                userp->seconds = 0;
                        else if (g.modems_free > g.users_waiting)
                                userp->seconds = 0;
                        else if (g.max_busy->seconds >= TIME)
                                userp->seconds = 5 * 60;
                        else
                                userp->seconds = TIME -
                                        g.max_busy->seconds + 5 * 60;
                }

                if (!svc_sendreply(svcp, xdr_USER, userp))
                        fatal("svc_dispatch: svc_sendreply");
                break;
        case GETUSERBYUID:

		:
		:

        default:
                printlog(LOG_WARNING, "svc_dispatch: unknown request %d",
                        rqstp->rq_proc);
                svcerr_noproc(svcp);
                break;
        }
}

-------------------------------------------------------------------------------
Henk Schouten					email:     henks@hhinsi.uucp
Software Expertise Center			or:        sec@hhinsi.uucp
Haagse Hogeschool - Sector Informatica
Louis Couperusplein 2-19			phone:     (31) 70 618419
2514 HP The Hague, The Netherlands		fax:       (31) 70 618599
-------------------------------------------------------------------------------
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 10:27:03 GMT
From:      eru!luth!sunic!mcsun!hp4nl!tnosoes!tom@bloom-beacon.mit.edu  (Tom Vijlbrief)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof, A SOLUTION FOR INTERNET SECURITY ?
We will join the internet quite soon and we are concerned about security too.

I changed a version of Phil Karns KA9Q TCP/IP package so it acts as a
secure gateway. The idea is that security is established at the gateway
so that one need not secure every host.

If there is enough interest then I'll make the binary (and source if you
are paranoid) available.

The needed hardware is a PC-compatible and two ethernet cards.

The only drawback is a slight loss of speed, but internet bandwidth
would often be the limiting factor.

This is an extract of the README:
=======================================================

SECURITY Features
=================

This version of net can act as a secure gateway between a local net
and an external IP network.

It allows connections to be initiated from the local network(s) to the
external network(s) but it disallows all connection attempts from the
external networks(s) the the local network(s).

Note that the gateway itself is always accesible over all interfaces.
So it can act as FTP server for the external insecure networks.
(This has ofcourse a negative impact on its performance as a
secure internetwork router.)
Be carefull to configure the file '\ftpusers` before you start FTP service
with the 'start ftp' command. Disallow access to the root directory or the
NET binary!


The insecure external network interface has to be attached with a name
that starts with 'Se' (Secure).

The local network(s) has to be specified with the command:

secure localnet <network>[/<bits>]

Example: secure localnet [140.24.67]/24

This will add the specified network to the list of protected (local) networks.

The protection is established by examination of packets which enter the network
over the 'Secure' interface:

1:
==
A packet which has an IP-source which matches one of the specified local
networks is considered a faked packet and is simply dropped. A warning
is written in the logfile.

2:
==
Every UDP packet is rejected with an ICMP Port Unreachable message.

3:
==
Every TCP packet with a port destination number < 1000 is rejected
with an ICMP Port Unreachable number.

4:
==
ICMP redirect packets are dropped.


Local networks (or hosts) can be completely isolated from the external networks
by specifying a 'sink' route. The will reject EVERY packet with an
IP-source or IP-destination that matches the specified sink route with
an ICMP Host Unreachable message.

Example:

route add lonely sink
route add [140.24.67.128]/25 sink

Tracing
=======

The command: secure trace on
will trace incoming packets on the 'Secure' interface. Remember that
turning trace on has a negative impact on routing performance.

Creating (dangerous) exceptions
===============================

It is possible to allow TCP connections to special hosts in order to
establish anonymous FTP connections or incoming mail.

This can be very dangerous because many older Unix FTP- and SMTP-
(= sendmail) daemons have dangerous security holes. A safe alternative
is to use a PC which runs this NET program as anonymous FTP server.

Many mail SMTP (and FTP) daemons have the famous Morris internet worm holes.
Do not allow connections until you are certain that your version is
secure. The safest way to assure this is to install the latest
Berkeley sendmail and ftpd sources which are publicly available.
The use of mail-aliases which resolve to programs (like |uudecode) is
also considered insecure.

This is an extract of:
===============================================================================
			    CERT Advisory
			    March 19, 1990
		      Internet Intruder Warning
-------------------------------------------------------------------------------
3) Exploit holes in sendmail.

   Make sure you are running the latest sendmail from your vendor.
BSD 5.61 fixes all known holes that the intruder is using.  


4) Exploit bugs in old versions of FTP; exploit mis-configured
   anonymous FTP

   Make sure you are running the most recent version of FTP which is
the Berkeley version 4.163 of Nov.  8 1988.  Check with your vendor
for information on configuration upgrades.  Also check
your anonymous FTP configuration.  It is important to follow the
instructions provided with the operating system to properly configure
the files available through anonymous ftp (e.g., file permissions,
ownership, group, etc.).  Note especially that you should not use your
system's standard password file as the password file for FTP.

9) Examine the /usr/lib/aliases (mail alias) file for unauthorized
entries.  Some alias files include an alias named 'uudecode'; if this
alias exists on your system, and you are not explicitly using it, then
it should be removed.
=========================End of CERT extract===============


After you have convinced yourself that your Unix servers are really
secure you can execute an secure allow command.

Example: secure allow mailhost 25

This will allow TCP connections to be established over the Secure
interface to tcp port 25 on host 'mailhost'. 25 is the TCP port number
of the SMTP mail daemon.

===============================================================================
Tom Vijlbrief
TNO Institute for Perception
P.O. Box 23				Phone: +31 34 63 562 11
3769 ZG  Soesterberg			E-mail: tnosoes!tom@hp4nl.nluug.nl
The Netherlands				or: uunet!hp4nl.nluug.nl!tnosoes!tom
===============================================================================
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 10:57:53 GMT
From:      cucstud!tfd!tons61!harrys@uunet.uu.net  (Harry Skelton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <447@illini.osc.edu> djh@osc.edu (David Heisterberg) writes:
>In article <1990Apr20.192233.4092@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
>> In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>> >... There are lessons to be learned, starting with the
>> >abolishment of /etc/passwd and user access to the encryption
>> >algorithm.
>> 
>> Ah yes, good old security-through-obscurity.  Where have we heard that
>> before?
>
>I think that's hardly a fair criticism.  I don't see how the original
>article could be read as advocating security-through-obscurity.  What's
>unreasonable about hiding sensitive information in addition to doing a
>good job of providing real security?  Of course, if you *rely* on hiding
>the password file then I agree you're in trouble.
>
>David J. Heisterberg		djh@osc.edu		And you all know
>The Ohio Supercomputer Center	djh@ohstpy.bitnet	security Is mortals'
>Columbus, Ohio			ohstpy::djh		chiefest enemy.

I think what should be done is the source code for FTP to be published and
allow the local site to include security measures for such a problem. Like
a chroot() before any work is done, or allocate spool directories that work
like the chroot command/uucp environments.  This would resolve all of these
problems.

i.e. (ftp config file)

user1:<password>:/root-working/dir
user2:<password>:/root-working/dir
anon::/remote-spool/dir

etc...

This way CWD's will not allow the user to get out of the "pit" that the
config file has dug. Also this would limit users from ftp'ing into other
user work areas or into security areas.

Sort of the same effect I get when I FTP into my MVS machine.
-- 
Harry Skelton - Senior Systems Administrator - U.S. Dept. of Transportation
             via: apple, tfd, c3pe, jando, sir-alan, obdient
[  Views expressed by Harry Skelton are not those of the US Gov. or CBSI  ]
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 11:11:37 GMT
From:      mcsun!hp4nl!uvabick!matthew@uunet.uu.net  (Matthew Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   Wanted:  How do you set up a resonably SECURE anonymous FTP?
Hello!  I have been following this discussion with interest.  With any sort of
luck, we will be joining the Internet in a matter of weeks.  I would like
to have an anonymous FTP possibility, dangers notwithstanding.  Does
anyone have a simple (:-) step-by-step guide to setting up anonymous FTP,
with some guidelines of what to avoid?

Thanks in advance.  I'll summarize any e-mail, if there's anything to
summarize...

Matthew Lewis
-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
31-20-52 51 220					1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands
UUCP:	  uunet!mcsun!hp4nl!uvabick!matthew
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 11:20:44 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!deimos.cis.ksu.edu!ksuvax1.cis.ksu.edu!tar@tut.cis.ohio-state.edu  (Tim Ramsey)
To:        tcp-ip@nic.ddn.mil
Subject:   Has anybody implemented an on-demand rwho?
Our campus network guru has expressed displeasure with my running rwhods
on several systems on the campus net.  Something like, "...we get to see all
your stinking RWHO blasts every couple minutes from all your stinking hosts
which are all stinkingly synchronized for some stinking reason..." (reprinted
without permission :-)  It seems to me that it wouldn't be too hard to
modify rwho to send out a broadcast packet on its own, which would be picked
up by rwhods that have been modified to reply only when queried.  Sort of
like the "rusers" program that uses RPC to do the same thing.

You will still have stinking broadcasts, but not every stinking minute, and
not from every stinking host.  That might make our guru happier.

Before I go attack the source, has anybody else done this?  If so, could
you send me diffs against whatever version of rwho/rwhod you have?

Thanks,

Tim
--
Tim Ramsey                         Dept. of Computing and Information Sciences
Internet: tar@ksuvax1.cis.ksu.edu  Kansas State University, Manhattan KS 66506
UUCP:  ...!{rutgers,texbell}!ksuvax1!tar   (913) 539-4977 (voice) 2-7114 (FAX)
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Apr 90 15:38:08 EDT
From:      barns@gateway.mitre.org
To:        pilchuck!amc-gw!ttrnds!morpho!news@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP Window Question
If your description is correct, both implementations are broken.  You
should beat on the sender vendor first, since their part of the
process is more indispensable.

Only the receiver can open the window.  However, since there is no
assurance of reliable delivery for a TCP segment that doesn't contain
data (which is the common case for reopening a window that went to 0),
it is required that the sender perform "zero window probing" repeatedly
in order to try to elicit an acknowledgement that contains a nonzero
window.  If the receiver is not ready to open the window, it must
respond to this probe with an acknowledgement that contains a zero
window.  (Although it MUST respond, it doesn't have to acknowledge the
octet of data that was in the probe segment.  Usually the ack sequence
number doesn't change until the window is reopened.)  The intent is
to allow an intentional zero window condition to persist indefinitely
but assure that an unintentional zero window condition will be fixed
within some reasonable period of time.  In addition to solving the case
it is meant to solve, this mechanism tends to overcome wedged conditions
caused by flawed implementation on the receiver side.

Zero window probing is documented in the TCP specification, RFC 793,
section 3.7, beginning with the fourth paragraph under "Managing the
Window"; it is reiterated (and some implementation recommendations are
provided) in Host Requirements-Communication Layers, RFC 1122, section
4.2.2.17.  If your vendors believe in MIL-STDs, refer them to
MIL-STD-1778, section 9.2.3.2.  Implementors are given some latitude
in defining the frequency of zero window probing.  However, 'never' is
definitely unacceptable.  RFC 1122 says you may clamp the backoff on
the probe interval, but doesn't suggest a value.  I still like a two
minute maximum.

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

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 13:41:02 GMT
From:      zaphod.mps.ohio-state.edu!samsung!umich!srvr1!ant.engin.umich.edu!fozzy@tut.cis.ohio-state.edu  (Eric Wines)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <2672@husc6.harvard.edu> kovar@popvax.uucp (David C. Kovar) writes:
>In article <1990Apr19.205930.15589@caen.engin.umich.edu> fozzy@caen.engin.umich.edu (Eric Wines) writes:
>>I think you are quite wrong.  To be on the internet these days your 
>>system had better be secure.  Your login accounts had better have good
>>passwords, your ftp had better be secure, etc.  It would extremely trivial
>>to query every entry in /etc/hosts for ftp version information.
>>If it is really a hole don't you think there are hacker's that have
>>exploited it?
>>  Would I be wrong to tell a co-worker that some idiot sysadmin at bozo.com
>>has root wide open without a password (just an example).
>
>  So, if in the course of my normal, legal wanderings around the Internet
>I find that your machine has a security flaw I should immediately post
>to alt.security saying "Machine X has a security flaw Y and this is how
>you exploit it?" I sincerely hope that this is not what you mean. 

Of course not.  I wouldn't suggest that you should point out specific flaws
at specific sites.  When discussing something like ftp, I don't think it's a
big deal to pick a host at random out of /etc/hosts and use it as an example.
Obviously you're not going to mention how to crack the host.  Showing
the login information and saying something like "this version of ftp is
three years old, people are still running old versions of ftp and many of
these are not entirely secure" just isn't a big deal to me.  Pointing out
an excellent example of a well known hole that has been ignored by
a large (?) number of sites is a good thing.

>  Yes, you should keep your machine as secure as possible if you're going
>to attached yourself to a public network. I've no problems at all with
>that. But if you discover a hole in my system and tell everyone else before
>you tell me about it, I am going to be quite upset. And, if breaking into
>my system is illegal, and you are party to an illegal act by passing
>on that information, then you've also just broken the law.

I think you're stretching things a bit.  Certainly a list of systems
and their security weaknesses isn't going to be posted (well, at least
not on Usenet. I'm sure it's common on BBS's with cracking information).
I think it would be very interesting to write some shell scripts to gather
*statistical* information about fairly blatant security weaknesses on internet
hosts, but I'm sure not going to do it.
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 14:16:24 GMT
From:      new@louie.udel.edu  (Darren New)
To:        tcp-ip@nic.ddn.mil
Subject:   The Estelle FDT
Does anybody know of an FTP site with machine-readable versions
of Estelle specifications of real-world protocols?  For example,
we have ISO VTP in Estelle.  If there are enough responses, I 
could start an FTP site at UDel for any freely-distributable
specifications.  I would also like to see any specifications
of TCP/IP-based protocols.    
      (Alternating Bit is getting a little stale :-)
      Thanks!    -- Darren
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 15:12:28 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP/IP Window Question


John:

    The sending TCP is required to periodically probe the receiver to
see if the receiver has opened its window.  Here's the relevant text
from RFC 1122.  Inform your vendors that reading is a required skill
in networking.


     4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42

	Probing of zero (offered) windows MUST be supported.

	A TCP MAY keep its offered receive window closed
	indefinitely.  As long as the receiving TCP continues to
	send acknowledgments in response to the probe segments, the
	sending TCP MUST allow the connection to stay open.

	DISCUSSION:
	     It is extremely important to remember that ACK
	     (acknowledgment) segments that contain no data are not
	     reliably transmitted by TCP.  If zero window probing is
	     not supported, a connection may hang forever when an
	     ACK segment that re-opens the window is lost.

	     The delay in opening a zero window generally occurs
	     when the receiving application stops taking data from
	     its TCP.  For example, consider a printer daemon
	     application, stopped because the printer ran out of
	     paper.

	The transmitting host SHOULD send the first zero-window
	probe when a zero window has existed for the retransmission
	timeout period (see Section 4.2.2.15), and SHOULD increase
	exponentially the interval between successive probes.

	DISCUSSION:
	     This procedure minimizes delay if the zero-window
	     condition is due to a lost ACK segment containing a
	     window-opening update.  Exponential backoff is
	     recommended, possibly with some maximum interval not
	     specified here.  This procedure is similar to that of
	     the retransmission algorithm, and it may be possible to
	     combine the two procedures in the implementation.


Craig

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 17:12:35 GMT
From:      ucla-seas!scw@cs.ucla.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Difference between U.S. GOSIP and U.K. GOSIP
In article <4049@infmx.UUCP> kwang@infmx.UUCP (Kwang Sung) writes:
>	I've just got U.K. GOSIP documents. Does anybody already know what
>is difference between U.S. GOSIP and U.K. GOSIP for each layer ??
>Please let me know. Thanx.

Gladly,
    The difference between UK gossip and USA gossip lies in the ratio of
gossip about the Royals to gossip about the Movie Stars and Rock Singers.
In the UK the Royal Family...What? That's GOSIP not gossip?...
Oh well, never mind.
-----
Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (213)-825-8614
UUCP: ...!{ibmsupt,hao!cepu}!ollie}!scw  Internet:scw@SEAS.UCLA.EDU 
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 17:31:43 GMT
From:      sgi!davidf%colnago.wpd.sgi.com@ucbvax.Berkeley.EDU  (David Fenstemaker)
To:        tcp-ip@nic.ddn.mil
Subject:   ADAX X.25
Does anyone out there have any experience with the ADAX suite
of X.25 products, both hardware and software, both positive
and negative? 

I understand that Tandem, AT&T and HP OEM
software and hardware from them. They are out of Berkeley.

Thanks,

David
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 18:08:04 GMT
From:      mcsun!ukc!tcdcs!swift.cs.tcd.ie!ul.ie!bourkej@uunet.uu.net  (John Bourke)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for 'extras' to V6.4 CMU-TEK ???
Does V6.4 of CMU-TEK support SLIP.  If not, has anyone written SLIP or any other
protocols for it ?

Is there any way to setup SLIP as a LAT service on the VAX, so a package like
ka9q can 'dial up and connect' to it ?

John Bourke
<bourkej@ul.ie> 
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 19:01:52 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <12672@smoke.BRL.MIL> w8sdz@smoke.BRL.MIL (Keith Petersen) writes:
>It seems to me that there is a simple solution to the problem of
>anonymous ftp users being able to download /etc/passwd.  Hard code
>a restriction into ftpd against being able to transfer any files named
>"passwd" whether or not there was a path name included.

This is a bandaid.  What is needed is either a shadow file that only
root can read or some program that will go through a passwd file and
replace all the real, live passwords with a single star, so that it
can be placed in ~ftp/etc/passwd and no one would care if you got this
file.  Also, if you did implement this, what is to keep me from using
the rename command (or some command that you hadn't thought to put the
check in) to get this file?  Special cases usually cause more security
holes than they fix.

The more serious problem on the net these days is that TFTP (not
anonymous FTP) allows anybody on the net to get any world readable
file on your system.  This includes /etc/passwd.  TFTP should be fixed
to allow only certain classes of hosts access via TFTP.  A more
drastic step might be to restrict what files can be transfered with
TFTP.  This will help build a wall around your site, but it won't do
much to help protect you against internal hackers.  Totally disabling
TFTP would do that, but then you can't boot all those diskless
workstations that you have hanging around any more.

Oh, one last thing about any security implementation: It should come
from the vendor secure and have instructions for making it more open
with the dangers clearly spelled out so that the system admin people
can make intelligent, informed decisions.

Warner Losh
imp@solbourne.com	imp%stan@boulder.colorado.edu
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 19:54:34 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!bygg@ucsd.edu  (Johnny Eriksson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Apr24.190152.14694@Solbourne.COM> imp@dancer.Solbourne.COM (Warner Losh) writes:

> The more serious problem on the net these days is that TFTP (not
> anonymous FTP) allows anybody on the net to get any world readable
> file on your system.  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Well, my (possibly very naive) interpretation of "world readable"
is "readable by anybody in the world".  Or am I missing something?

> Warner Losh
> imp@solbourne.com	imp%stan@boulder.colorado.edu

--Johnny
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 90 21:24:23 GMT
From:      escher@apple.com  (Michael Crawford)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP Window Question
In article <9004241325.AA02202@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
>It is the transmitting station's responsibility to re-schedule transmission.
>Too many vendors/implementors tend to forget that the transmitting station is
>the active component and fail to implement robust transmission strategies
>regardless of the communication protocol.
>
>Merton

More specifically, RFC 793, page 42, states:

The sending TCP must be prepared to accept from the user and send at least one
octet of new data even if the send window is zero.  The sending TCP must regularly 
retransmit  to the recieving TCP even when the window is zero.  Two minutes is
recommended for the retransmission interval when the window is zero.  This
retransmission is essential to guarantee that when either TCP has a zero window the
re-opening of the window will be reliably reported to the other.

RTFM.  It's good for you ;-)

-- 
Michael D. Crawford
Oddball Enterprises
606 Modesto Avenue
Santa Cruz, CA 95060
oddball!mike@ucscc.ucsc.edu

Consulting for Apple Computer Inc.
escher@apple.com
Applelink: escher@apple.com@INTERNET#

The opinions expressed here are solely my own.
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Apr 90 09:43:53 -0700
From:      jqj@rt-jqj.Stanford.EDU
To:        stan!dancer!imp@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
>World readable usually means "Readable by anybody who is logged in to
>your machine with a valid account."

Actually, although this was once true, it needs to be qualified in an era
of network file systems and complex network file access protocols.  We have
been discussing only the security of ftp, but it is worth broadening the
discussion by recognizing that there are other file access protocols in
common use with different semantics for general or public access.

In the Unix world, "World" doesn't have a particularly precise semantics,
though perhaps "other" (defined by the switch letter used in chmod, e.g. 
"chmod o+r filename") does.  So lets use "Other" to refer to access governed
by that field in the mode word.  In a VMS world, "World" (the word again
mandated by the command syntax) refers to a similar but not identical notion
of "everybody else".  We might want to reserve "World" for the VMS semantics.

Let's leave aside rcp, which is known to be a security disaster even if it
doesn't have any notion of "public" access.  And FTAM, which we don't use
enough (yet) for it to matter.

However, we should still ask ourselves what "publicly readable" means to a
system that exports AFS or NFS or ... file systems.  For example, NFS
introduces the user id "nobody" with special semantics -- a remote root, and
others who do not have an account on your machine may end up having "nobody"
access to your files.  In an AFS world, somebody not logged into your machine
(e.g. because she is in a completely different cell at some different
university) will have "system:anyuser" access to files, and there is a
separate level of protection for people logged into your cell, but being
logged into your machine is pretty much irrelevant.  Other distributed file
systems (Novell, etc.) have similarly complex notions of default or public
access.

The bottom line is that "public" file access semantics are now much more
complex than they were when anonymous ftp was invented.  "Complex" of course
often translates into "error-prone".
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Apr 90 11:26:32 PDT
From:      braden@venera.isi.edu
To:        mcc@wlv.imsd.contel.com, pilchuck!amc-gw!ttrnds!morpho!news@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP Window Question

	It is the transmitting station's responsibility to re-schedule transmission.

No, both sides are involved.  The problem is not retransmission, it is
initial transmission.  The receiver must send a (presumably empty) ACK
segment to open the window.  The transmitter must "slowly" probe the
closed window in case this ACK segment gets lost.  The second "must" in
called out in section 4.2.2.17 of RFC-1122; the first "must" was
considered so obvious we did not think to include it.

Bob Braden

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Apr 90 08:35:57 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        bzs@world.std.com, ogicse!blake!Tomobiki-Cho!mrc@UCSD.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  anonymous ftp, and the dangers thereof
From: bzs@world.std.Com ( Barry Shein )

>Something I always thought would help would be if when, a system is
>installed, the admin would be asked to enter a string which perturbed
>the password encryption algorithm on that one machine (or cluster, if
>desired.) This could probably be reasonably secured and no one ever
>need know that string again if it's done right (the key code could be
>carried, encrypted, through system software upgrades etc.)

I'm not a crypto-freak, but I've done a little reading on the black
art and isn't this called a Key?

The problem with the approach is the system remembering the key.
It must be in alterable - so I can customize it, permanent - so I
do not have to re-enter the key every boot, and protected - so YOU can
not see the key.

The best place to put this kind of information would be someplace
that only the Kernal can read - e.g. a hidden hunk of disk someplace
(not in the file systems) or maybe NVRAM protected by the MMU
hardware.

Cheers
Frank Kastenholz
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 05:17:01 GMT
From:      stan!dancer!imp@uunet.uu.net  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Apr24.190152.14694@Solbourne.COM> I write:
> The more serious problem on the net these days is that TFTP (not
> anonymous FTP) allows anybody on the net to get any world readable
> file on your system.  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In article <1316@sunic.sunet.se> bygg@sunic.sunet.se (Johnny Eriksson) writes:
>Well, my (possibly very naive) interpretation of "world readable"
>is "readable by anybody in the world".  Or am I missing something?

World readable usually means "Readable by anybody who is logged in to
your machine with a valid account."

So, TFTP will allow anybody on the INTERNET, many of its millions of
users you don't know and who don't have a valid account on your
system, to read any file on your system that has the "world read" bit
set in the file protection.  Most of these files aren't real
interesting, but some (like /etc/passwd) are valuable to crackers.

So basically you have opened most of the files on your system to
anybody that wants to even think about looking at them.  Some versions
of TFTP do exist that allow you to restirct paths/tress/files/etc that
can be gotten, but most don't.

-- 
Warner Losh		imp@solbourne.com
For a secure system:  Place the on/off switch in the OFF position.
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Apr 90 14:42:19 EDT
From:      Michael A. Patton <MAP@lcs.mit.edu>
To:        stan!dancer!imp@boulder.colorado.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   anonymous ftp, and the dangers thereof
   Date: 24 Apr 90 19:01:52 GMT
   From: stan!dancer!imp@boulder.colorado.edu  (Warner Losh)

   What is needed is ... some program that will go through a passwd
   file and replace all the real, live passwords with a single star,
   so that it can be placed in ~ftp/etc/passwd and no one would care
   if you got this file.

In fact this is so simple, I did it first thing on installing
anonymous FTP then forgot all about it until you brought it up (I went
to write it and discovered I already had :-), the script is below.  I
run it from cron every day at some wee hour of the morning.

   The more serious problem on the net these days is that TFTP (not
   anonymous FTP) allows anybody on the net to get any world readable
   file on your system.  ...  TFTP should be fixed ...

I'm working on this, too.  There are several implementations of
"secured TFTP" running around.  Some are not actually secure, they
just seem to be.  Most of the secure ones don't let you have any
really world readable files and also restricted distribution files.
Someone here is working on one that will allow a directory for really
world-readable files and also directories only available to certain
hosts.  Be careful, however, host addresses are not secure IDs, I plan
to only use this for booting machines on the same wire.

	    __
  /|  /|  /|  \		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. :-)


Script for keeping ~ftp/etc/* up to date, cut between lines.
----------------------------------------------------------------
#! /bin/csh
cd ~ftp/etc
/bin/awk -F: '$1!=""{printf "%s:*:%s:%s:-:/pub/%s:\n",$1,$3,$4,$1}' /etc/passwd >passwd
/bin/awk -F: '$1!=""{printf "%s:*:%s:\n",$1,$3}' /etc/group >group
----------------------------------------------------------------
See, simple isn't it...  It even sets the "home directory" relative to
how the anonymous FTP area is set up.  Here's what my line looks like,
if anyone can guess my password from that, I'd be amazed.

map:*:11059:10:-:/pub/map:
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Apr 90 19:11:29 -0400
From:      bzs@world.std.com (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   anonymous ftp, and the dangers thereof

>The best place to put this kind of information would be someplace that
>only the Kernal can read...or maybe NVRAM protected by the MMU
>hardware.

Bingo, NVRAM and a device (like the DES chips) to feed the string
thru.

If setting of the system key was limited to someone with access to the
PROM monitors (that is, had to bring the system down, maybe had to
insert a real metal key) I think the problem can be reduced a lot.

It's then virtually impossible for me to use my machine to work on
your password file without that key (the device, given a password try
and the "external" encryption, perturbs and runs the algorithm,
returning true or false.)

Having the algorithm it uses is useless without the NVRAM key that's
been set. A system admin could choose to set a cluster of machines to
use the same key if desired (e.g. for password file sharing.)

I suspect that such things exist, or close analogues, but are just not
popularized. Why? Well, for starters, security is like the weather,
everyone talks about it, but no one wants to pay for it (?)

>Cheers
>Frank Kastenholz

Rah Rahs

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 12:37:19 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!bygg@ucsd.edu  (Johnny Eriksson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Apr25.051701.5215@Solbourne.COM> imp@dancer.Solbourne.COM (Warner Losh) writes:
   In article <1316@sunic.sunet.se> I write:
   >Well, my (possibly very naive) interpretation of "world readable"
   >is "readable by anybody in the world".  Or am I missing something?

   World readable usually means "Readable by anybody who is logged in to
   your machine with a valid account."

   So, TFTP will allow anybody on the INTERNET, many of its millions of
   users you don't know and who don't have a valid account on your
   system, to read any file on your system that has the "world read" bit
   set in the file protection.  Most of these files aren't real
   interesting, but some (like /etc/passwd) are valuable to crackers.

If a file contains data that can be of use for crackers, it should NOT
be world readable.  This is independent of how we interpret "world",
system wide or network wide.

   So basically you have opened most of the files on your system to
   anybody that wants to even think about looking at them.  Some versions
   of TFTP do exist that allow you to restirct paths/tress/files/etc that
   can be gotten, but most don't.

When a system is connected to a network, it is no longer an entity of
its own.  It is a part of that network, and it should be viewed in
that way.

   For a secure system:  Place the on/off switch in the OFF position.

True.  It's a pity most people don't know that.
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 12:46:10 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!lethe!yunexus!davecb@ucsd.edu  (David Collier-Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
harrys@tons61.UUCP (Harry Skelton) writes:
>allow the local site to include security measures for such a problem. Like
>a chroot() before any work is done, or allocate spool directories that work
>like the chroot command/uucp environments.  This would resolve all of these
>problems.

  I'd suggest something to add to the source availability, and to be
provided even in the absence of source: a proof outline demonstrating that
the restrictions are met by the mechanisms used in the code, and stating
what they are.

  I did outlines in a previous life for a B-level workstation boot, and they
were short, succinct and almost readable.  Admittedly, they were hard to do.

How about:  
	This mechanism will ensure that only files in the directories
	"under" the chroot-point are acessable:

	if program is not setuid-root,
		program exits forthwith
	if program is setuid-root
		program changes directory to chroot-point
		program changes root to chroot-point
		program gives up privilege by setting euid to uid.

	Note that this does not protect the system from any manipulations
	that the program does to the directorys below the chroot-point, only
	limits changes to files outside that area.

Corrections and suggestions welcome!

--dave c-b
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | "And the next 8 man-months came up like
CANADA. 416-223-8968  |   thunder across the bay" --david kipling
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 16:15:02 GMT
From:      henigan@quando.UUCP (Kevin Henigan)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Looking for fast file-transfer on ethernet


Hi,

I want to do a fast file-transfer between hosts using ethernet.

I have implemented one file-transfer is based on the BSD socket interface
with TCP protocol. My problem is that the transmission rate is too slow,
so to speed things up I want to do the same with UDP protocol, but UDP
is unreliable.

What I'm looking for is an interface that supports reliable byte/sec streams
using UDP.

Any ideas ????

Many Thanks, for any replies.

Please DON'T send sources, send me mail first...

-- 
 Kevin Henigan. UUCP:     {backbone}!unido!quando!henigan OR henigan@quando.uucp
  Quantum GmbH  Bitnet:   UNIDO!quando!henigan OR henigan%quando@UNIDO(.bitnet)
    Dortmund    internet: henigan@quando.quantum.de
    Germany     advert  : space to rent..

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 18:22:06 GMT
From:      fed!m1rcd00@uunet.uu.net  (Bob Drzyzgula)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for SunOS 4.1
Has anyone tried and/or succeded getting SLIP running on SunOS 4.1?

Thanks,

Bob Drzyzgula
Federal Reserve Board
rcd@fed.frb.gov
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 18:22:32 GMT
From:      venus!yalevm!maine!shanley@CS.YALE.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Host doesn't recognize itself
Equipment:  3B2-400
            Unix 3.1
            Wollogong Enhanced TCP/IP Win/3B Interface 2.1
            Ethernet Board
            10 Based 5 Ethernet N.I Drivers
 
/etc/hosts entry:  130.111.115.11 umofm.umeofm.maine.edu umofm
 
Problem:  When I send mail to shanleyc@umofm everything works fine.
 
          When I send mail to shanleyc@umofm.umeofm.maine.edu my
          postmaster returns it with a 550 Host unknown.
 
          What is going on?
 
************************************************************************
Kevin Shanley                 uunet!usm3b2!mdotscr!mdotbgr!umofm!shanley
System Administrator          shanley@maine.maine.edu
Facilities Management         Fax    207-581-2673
University of Maine           Voice  207-581-2681
Orono, Maine  04469           "The Capacitor"
************************************************************************
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 19:27:11 GMT
From:      brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!chris@apple.com  (Christopher Martin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  anonymous ftp, and the dangers thereof
In article <9004251235.AA01391@europa.Com> kasten@europa.interlan.COM (Frank Kastenholz) writes:
>From: bzs@world.std.Com ( Barry Shein )
>
>I'm not a crypto-freak, but I've done a little reading on the black
>art and isn't this called a Key?
>

Actually, I believe the key is derived from the clear-text password and
that the "clear-text" to be encrypted is a site-dependent (usually zero)
constant.  I believe that Barry was discussing changing this constant.

-- 

Christopher Martin                 INTERNET:  cmartin@uiuc.edu
University of Illinois at U-C      UUCP:      {uunet, ...}!uiucuxc!ux1!chris 
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Apr 90 07:08:44 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        straw@pizza.cam.nist.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP agent software for Sun
Please re-direct your message to snmp@nisc.nyser.net, where many answers
can be supplied.  You might start by looking in RFC1147.  Of course, the
vendor of the platform you mentioned will sell you a product.  In
addition, there are about half a dozen companies who will sell you
supported product.  Further, there are at least
three openly available agents you could use.

/mtr

"SNMP-- it's been implemented more times than TCP..."  (-:
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 19:40:57 GMT
From:      dev!vrdxhq!williams@uunet.uu.net  (Tim Williams)
To:        tcp-ip@nic.ddn.mil
Subject:   RIP
Is there any GOOD documentation on RIP (header formats and implementation
issues) that is accessable (book, paper, or whatever).  I am beginning
a project to write an IP router from the ground up and I am in need of
as much documentation as possible.

Thanks in advance
Tim Williams
williams@verdix.com
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 90 21:19:24 GMT
From:      lll-crg.llnl.gov@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   file transfer and buffer sizes

    In most versions of FTP that I have seen, I have noticed that a buffer size
of 1 KBytes is generally used for disk reads and subsequent writes to the net.
It has always struck me as somewhat inefficient for a file transport application
to use such a small user buffer.  Why not use 4K or 8K?
    I have also wondered why these implementations have not utilized the
setsockopt() system call to increase the high-water mark.  This would certainly 
improve performance of the server.
    I have vague suspicions as to why things are as they are (e.g. attempting 
to constrain both host and network resource utilization), but I would like to
hear from others regarding this.  I know that the setsockopt() for increasing
the high-water mark could not be used in certain cases since it was not an
option (e.g. Sun OS3.x) but on other systems, it was available and not used.
    One other question (which may become clear from any answers regarding the 
above question):  Would it be considered bad form to build an FTP server which 
used 64K read buffers with the high-water mark set up to 32K?

    Thanks in advance.  I don't know if it's best to respond via email or to
post - I will summarize if emailed.

mb
booloo@lll-crg.llnl.gov
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 01:10:11 GMT
From:      gkn@ucsd.edu  (Gerard K. Newman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: file transfer and buffer sizes
In article <56910@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>
>    In most versions of FTP that I have seen, I have noticed that a buffer size
>of 1 KBytes is generally used for disk reads and subsequent writes to the net.
>It has always struck me as somewhat inefficient for a file transport application
>to use such a small user buffer.  Why not use 4K or 8K?

The TGV Multinet FTP server and client use 16Kbyte buffers.

>    I have also wondered why these implementations have not utilized the
>setsockopt() system call to increase the high-water mark.  This would certainly 
>improve performance of the server.

Also done in TGV Multinet, to good advantage.


Cheers,

gkn
San Diego Supercomputer Center
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Apr 90 08:18:05 PDT
From:      postel@venera.isi.edu
To:        dev!vrdxhq!williams@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  RIP

Tim Williams:

	RIP is described in RFC-1058.

--jon.
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 02:14:41 GMT
From:      HABERNOL@TUBVM.CS.TU-BERLIN.DE (Thomas Habernoll)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, and the dangers thereof, A SOLUTION FOR INTERNET SECURITY ?

Hi Tom,

>I changed a version of Phil Karns KA9Q TCP/IP package so it acts as a
>secure gateway. The idea is that security is established at the gateway
>so that one need not secure every host.

That's exactly what we will need real soon now, I'm afraid.
Are your modifications available? And if so, on which version of
KA9Q are they based? Should I add that I'd like to obtain a copy
of your modifications? :-)

  Thomas

Thomas Habernoll                   habernol@tubvm.cs.tu-berlin.de
Technical University of Berlin     habernol@db0tui11.Bitnet
TCP/IP grunt in the computing center of the Computer Science Department

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Apr 90 11:05:18 PDT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        tcp-ip@nic.ddn.mil
Cc:        gkn@ucsd.edu
Subject:   Re: file transfer and buffer sizes
>>     In most versions of FTP that I have seen, I have noticed that a buffer size
>> of 1 KBytes is generally used for disk reads and subsequent writes to the net.
>> It has always struck me as somewhat inefficient for a file transport application
>> to use such a small user buffer.  Why not use 4K or 8K?

> The TGV Multinet FTP server and client use 16Kbyte buffers.

    Actually, they use a 32Kbyte TCP window size (setsockopt()
SO_SNDBUF and SO_RCVBUF), but we read and write 16Kbytes at a time
with read() and write().  Oddly enough I found that maximum
performance occurs when the write() size is 1/2 the socket size.  (We
are running the Berkeley 4.3bsd-tahoe TCP/IP code and socket code in
the VMS kernel.)

    If the write size is less than 1/2 the socket size then the
writing application may have trouble keeping data on the output queue
due to scheduling delays.  Not keeping the device busy hurts
performance.  When the write size is exactly 1/2 the socket size you
get nice double-buffering and maximum performance.  If the write size
is equal to the socket size, performance goes down because every time
the socket drains the transmitter must sit idle while the process gets
scheduled, so oddly enough write size equal socket size gives the
WORST performance.  With the write size double the socket size
performance improves again, and keeps improving as you double it but
never gets as good as being 1/2 the socket size.  I didn't even
consider sizes not a power of 2 because of the optimizations in the
socket code which eliminate a data copy.

    Your mileage may vary -- under VMS a large write() request doesn't
require many process schedules to fill the socket -- just one. Depending
on the overhead of process scheduling under UNIX the same code might
not exhibit this behavior.

    Using this technique I've had people complain that the timing
statistics in our FTP were off by a factor of 2 because they couldn't
believe that FTP was faster than TTCP (which uses a smaller window size).

						    Kenneth Adelman
						    TGV, Inc.
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Apr 90 04:14:41 +0200
From:      Thomas Habernoll <HABERNOL%TUBVM.CS.TU-BERLIN.DE@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL, tnosoes!tom@hp4nl.nluug.nl
Subject:   Re: anonymous ftp, and the dangers thereof, A SOLUTION FOR INTERNET SECURITY ?
Hi Tom,

>I changed a version of Phil Karns KA9Q TCP/IP package so it acts as a
>secure gateway. The idea is that security is established at the gateway
>so that one need not secure every host.

That's exactly what we will need real soon now, I'm afraid.
Are your modifications available? And if so, on which version of
KA9Q are they based? Should I add that I'd like to obtain a copy
of your modifications? :-)

  Thomas

Thomas Habernoll                   habernol@tubvm.cs.tu-berlin.de
Technical University of Berlin     habernol@db0tui11.Bitnet
TCP/IP grunt in the computing center of the Computer Science Department
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Apr 90 15:21:05 PDT
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        lll-crg.llnl.gov@lll-winken.llnl.gov (Mark Boolootian)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: file transfer and buffer sizes
There certainly is no reason to have the file i/o size be the same as the
network buffer/datagram size.  On the other hand, it is quite dangerous simply to
make the file buffer as large as possible.

The reason is that your process can end up hanging, waiting to fill the file
buffer, but doing no network i/o because all of the network data has been
sent.

That is, you need to balance network i/o performance with disk i/o performance
and the "proper" balance depends upon the actual behavior of your particular
system.  (This is nothing but standard i/o pipelining, such as using
double-buffering for file i/o.)

Dave
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Apr 90 15:55:32 PDT
From:      mja@chico.simpact.com (Mike Anello)
To:        tcp-ip@nic.ddn.mil
Subject:   Remote Netstat

Does any have a public domain version of a remote netstat program available ?
I know about SNMP but I need something even simpler. Thanks.

Mike Anello
mja@chico.simpact.com
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Apr 90 17:55:23 PDT
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: file transfer and buffer sizes
Mark,

There certainly is no reason to have the file i/o size be the same as the
network buffer/datagram size.  On the other hand, it is quite dangerous simply to
make the file buffer as large as possible.

The reason is that your process can end up hanging, waiting to fill the file
buffer, but doing no network i/o because all of the network data has been
sent.

That is, you need to balance network i/o performance with disk i/o performance
and the "proper" balance depends upon the actual behavior of your particular
system.  (This is nothing but standard i/o pipelining, such as using
double-buffering for file i/o.)

Dave
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 11:08:31 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!lan!charly.bl.physik.tu-muenchen.de!k2@tut.cis.ohio-state.edu  (Klaus Steinberger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: seeking info on Acces Control List (ACL) mods to inetd
wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes:


>   Has anyone hacked inetd to consult an Access Control List or other
>   security extensions, ...

>Yes.  HP-UX has had this extension for several years.  We use the
>file /usr/adm/inetd.sec.  I've appended a sample to this message.

Is it possible to post the modifications to inetd ?
Or will it be propietary code?

I think there is some interest on the net for ACL's on inetd

Sincerely,
Klaus Steinberger
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende, D-8046 Garching, West Germany
BITNET:  K2@DGABLG5P            Internet: k2@charly.bl.physik.tu-muenchen.de
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 12:44:23 GMT
From:      cme!cam!straw@uunet.uu.net  (Mike Strawbridge)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP agent software for Sun
I am looking for available SNMP agent software for 4.3 BSD UNIX ...
specifically Suns. 

I would like to hear about all commercial and public domain SNMP packages
that run on Suns. I would especially like to hear from you if you have
experience with any of these.

I am not only interested in managing a TCP/IP network with a Sun. In our
case a Sun may be a managed device on the network (i.e. a Sun acting a
router between subnets).

Thanks.

-----------------------------------------------------------------------
NAME:   Michael Strawbridge             	TELE: (301) 975-3852
USMAIL: National Institute of Standards 	ARPA: straw@cam.nist.gov
		and Technology            	UUCP: uunet!cme-durer!straw
        Rm. B-146, Bldg. 225
        Gaithersburg, MD  20899
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 16:46:52 GMT
From:      smb@ulysses.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, and the dangers thereof

In article <9004251842.AA10242@gaak.LCS.MIT.EDU>, MAP@LCS.MIT.EDU (Michael A. Patton) writes:
>    From: stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
> 
>    What is needed is ... some program that will go through a passwd
>    file and replace all the real, live passwords with a single star,
>    so that it can be placed in ~ftp/etc/passwd and no one would care
>    if you got this file.
> 
> In fact this is so simple, I did it first thing on installing
> anonymous FTP then forgot all about it until you brought it up

Of course, I haven't really figured out any good reason to have any
/etc/passwd in ~ftp.  My solution is even simpler:  I omit the file
entirely.  'ls' doesn't seem to care; it just prints the numeric
uids.  If it did care, I'd leave a null file there.  After all,
why give away information?  A list of user names on some host --
complete with phone numbers, full names, and the like -- is very
useful to a cracker...

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 19:31:47 GMT
From:      oliveb!pyramid!athertn!joshua@apple.com  (Flame Bait)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about caching in UDP based RPC
In article <746@nikhefk.UUCP> henks@nikhefk.UUCP (Henk Schouten) writes:
>What is the matter? I have builded a client-server application using UDP
>based RPC. First I didn't use any caching at all, but when the machine
>got heavy loaded retransmissions were generated and remote procedures
>were executed more than once. 

Why not use TCP based RPC?  Assuming you write a little connection
management code, it will only be slightly slower than UDP based RPC.
It is true that it will limit the number clients which can talk to
a server at one time, but with SunOS 4.0.3 that limit is quite high
(over 30 processes, I think).

Caching can be thought of as a kludge which is needed to try to give
UDP the same reliablity as TCP.  Why not use TCP directly?

>My opinion about caching is that whenever
>an entry has to be added to the cache a check is needed to see if there
>is still enough room. If not, the oldest entry should be removed in favor
>for the new one. But, such thing does not happen. When the check points
>out that the cache is full, new space is allocated instead.

Your cache will not ensure execute at most once behavior.  Think about
a server and three clients.  The server gets an RPC from client 1,
then 2, then 3.  But it must trash the cache from client 1 in order 
to store client 3's result.  Now it gets a resend from client 1; it
will execute the service routine a second time.

The trick to caching UDP/RPC results it to cache exactly one result for 
each client the server has.  The cost is 8K per client, max.  You never
need to cache more than one response from each client, since a client 
will only send a new RPC only if the old one has been completed.

If you have any questions, send me email.  

Joshua Levy                          joshua@atherton.com  home:(415)968-3718
                             {decwrl|sun}!athertn!joshua  work:(408)734-9822 
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 21:16:00 GMT
From:      deimos.cis.ksu.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!dingler@rutgers.edu
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA Telnet Quick Reference Guide


Does anyone out there have a quick reference guide for the NCSA Telnet for the 
PC document?  I'm looking for a 1 to 4 page document that can act as a less
imposing document than the original distributed by NCSA. 
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 21:52:14 GMT
From:      galbp!bagend!bvsatl!bvs@gatech.edu  (bvs)
To:        tcp-ip@nic.ddn.mil
Subject:   Point to Point sources wanted
I am looking at the point to point protocol, with an eye towards
doing an implementation. The implementation needs to be pretty
portable, as the code must run  on a number of platforms.

I have the CMU implementation on-line here. Although it seems
to be a solid implementation, it is very closely tied to berkeley-on-a-vax.

Does anyone know of a reference implementation that is less deeply tied to 
B43 devices ?  I could work from the CMU code if I had to, but would
appreciate any pointers to other freely-distributable code sets.


Thanks in advance

Bill VerSteeg
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 90 23:52:54 GMT
From:      lm@snafu.Sun.COM (Larry McVoy)
To:        comp.protocols.tcp-ip
Subject:   Re: file transfer and buffer sizes

In article <56910@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>
>    In most versions of FTP that I have seen, I have noticed that a buffer size
>of 1 KBytes is generally used for disk reads and subsequent writes to the net.

I've noticed this too - it turns ftp benchmarks into kernel call benchmarks.
I'd crank 'em up - I set them to 8 or 16K in the Lachman code (I'm not sure 
that this made it into the product or not).

If you are running on a streams based TCP, diddling the high water marks in the
various modules can have some effect as well; I think the user buffer size
is the first order term, the high water mark the second order term.
---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.
    Besides, I frequently read news when I'm drjhgunghc, err, um, drunk.
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Apr 90 07:13:15 PDT
From:      margo@interlink.com (Margo Shrack)
To:        tcp-ip@nic.ddn.mil
Subject:   RDUMP question
I am looking for some feedback on experiences with using the rdump
utility, and would appreciate receiving any feedback on the following
points.  Please respond directly to 'margo@interlink.com' ... I will
summarize if there is any interest.

1.  How widely used is rdump?
2.  If you are currently using it, what are the advantages of using rdump?
3.  Are there any specific problems related to rdump?
4.  Is there any user resistance/acceptance to using rdump?
5.  What devices are you backing up to using the rdump utility?

My apologies for those seeing this message twice.  It didn't quite make
to all the recipients the first time.

Thanks,
    Margo

-----------------------------------------------------------
Margo Shrack			Product Marketing
margo@interlink.com		Interlink Computer Sciences
sun!iruucp!ntrlink!margo	47370 Fremont Blvd
				Fremont, CA 94538
Phone (415) 657-9800 x276	FAX   (415) 659-6381
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Apr 90 15:02:20 -0500
From:      dab@berserkly.cray.com (David Borman)
To:        lll-crg.llnl.gov@lll-winken.llnl.gov, tcp-ip@nic.ddn.mil
Subject:   Re: file transfer and buffer sizes
>    In most versions of FTP that I have seen, I have noticed that a buffer size
>of 1 KBytes is generally used for disk reads and subsequent writes to the net.
>It has always struck me as somewhat inefficient for a file transport application
>to use such a small user buffer.  Why not use 4K or 8K?
>    I have also wondered why these implementations have not utilized the
>setsockopt() system call to increase the high-water mark.  This would certainly 
>improve performance of the server.

Depending on your TCP implementation, you have to be careful when you
increase the high-water mark on the socket.  One of the few defeciences
of TCP is that there is no way for the remote side to tell you how much
data it is willing to send before it requires an ack, so that it can
free-up and re-use the buffers that are holding the data for possible
re-transmission.

If the TCP implementation assumes that the sender and the receiver have
the same buffer sizes, and is delaying acks until it has received at
least 1/3 of the window, then you can get into trouble.  If my buffers
are 32K, and the other sides buffers are 4K, then he'll send me 4K, and
wait for the ACK.  I'll sit there, waiting for more data.  After a bit,
without getting anymore data, the delayed ACK is sent.  Then the other
side frees up the buffers, sends another 4K, and we wait again.  This
can really destroy your throughput.

Van Jacobsons code in Tahoe release of 4.3BSD acknowledges at least
every-other packet, so as long as the senders buffer space is at
least twice as large as the packet size, things will be ok.  Systems
based on 4.2BSD (which didn't allow you to change the buffer sizes)
or the original 4.3BSD release will run into trouble.

Several years ago we put code into our TCP to keep track of the most data
ever sent into our window, and use that as an estimate of the senders
send space, rather than our using our local receive space as the estimate.

		-Dave Borman, dab@cray.com
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      27 April 1990 1346-PDT (Friday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        tcp-ip@nic.ddn.mil
Subject:   dec lanbrige 100
We have a dec lanbridge 100.  The documentation for it
(one slim pamphlet) mentions "remote bridge management
software" available for vms hosts.  Is there anything
available (publically?) for 4bsd/sunos hosts?

Thanks,

Ron
stanonik@nprdc.navy.mil
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 16:43:00 EDT
From:      "HQEIS::MCDANIEL" <mcdaniel%hqeis.decnet@hqafsc-vax.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: SRI-NIC.ARPA  IP NEEDED
Andrews AFB

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

                                        Date:     27-Apr-1990 04:34pm EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )


Subject: RE: SRI-NIC.ARPA  IP NEEDED


The attached Defense Data Network (DDN) Management Bulletin #72, 
dated 6 Apr 90, is provided for your information relating to the 
SRI-NIC.ARPA address and there New Network Addresses.  If you have 
any further questions, please call 1-800-235-3155, DDN Network 
Information Center and YES, they do help the INTERNET users.

Rodney A. McDaniel, DAFC
Information Systems Manager
Andrews AFB Md
Email: mcdaniel@hqafsc-vax.af.mil

*************************************************************************
DDN MGT Bulletin 72              DCA DDN Defense Communications System   
6 Apr 90                         Published by: DDN Network Info Center
                                     (NIC@NIC.DDN.MIL)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the NIC.DDN.MIL host [192.67.67.20]
using login="anonymous" and password="guest".  The pathname for
bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

                    NIC.DDN.MIL HOST ADDRESS CHANGE
                 AND ROOT DOMAIN SERVER ADDRESS CHANGE

In order for the NIC to provide better service, and because of the
phase-out of the ARPANET, the following changes have taken place and
are effective immediately (6 April 1990).

NIC.DDN.MIL
  The new address for host NIC.DDN.MIL is 192.67.67.20.

  The old ARPANET address for the NIC, 10.0.0.51, is no longer
  available, due to the phase-out of the ARPANET.

  The old MILNET address for the NIC, 26.0.0.73, will continue
  to be valid until 1 June 1990, after which service to this address
  will be discontinued.

ROOT DOMAIN SERVER
  The NIC's root domain server will run on a new host,
  NS.NIC.DDN.MIL at address 192.67.67.53.

  The old root server will continue to run on NIC.DDN.MIL
  until 1 June 1990.

New host tables and domain server files produced by the NIC will
reflect the new addresses.

Users should update host tables, domain server boot files, 
manuals, and documentation to reflect the new addresses.


The current list of root servers follows:

	   NS.NIC.DDN.MIL               192.67.67.53
	   A.ISI.EDU                    26.3.0.103
					128.9.0.107
	   AOS.BRL.MIL                  128.20.1.2
					192.5.25.82
	   C.NYSER.NET                  192.33.4.12
	   GUNTER-ADAM.AF.MIL           26.1.0.13
	   NS.NASA.GOV                  128.102.16.10
					192.52.195.10
	   TERP.UMD.EDU                 128.8.10.90
-------



-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 13:11:57 GMT
From:      dg!lewine@uunet.uu.net  (Don Lewine )
To:        tcp-ip@nic.ddn.mil
Subject:   Re: file transfer and buffer sizes
In article <56910@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>
>    In most versions of FTP that I have seen, I have noticed that a buffer size
>of 1 KBytes is generally used for disk reads and subsequent writes to the net.
>It has always struck me as somewhat inefficient for a file transport application
>to use such a small user buffer.  Why not use 4K or 8K?

The original ARPAnet reason was to reduce the number of retries.  The chance
of getting an error on an 8Kb packet is much higher than on a 1Kb packet.  
Now, that was in 1972 or so, but these decisions have a way of hanging on.
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 15:52:23 GMT
From:      att!cbnewsh!n2dsy@ucbvax.Berkeley.EDU  (j.gordon.beattie)
To:        tcp-ip@nic.ddn.mil
Subject:   ISO IP/TP-4 implementation help

I know this has been asked before, but can someone give me a
pointer to a Public Domain (or freely available) ISO IP and/or
TP-4 written in C?

Has anyone done any work to port ISODE to a ISO IP/TP-4 platform
thereby removing TCP/IP from the stack?

Thanks,




           J. Gordon Beattie, Jr.
E-mail:    att!hou2d!n2dsy (Unix) 
           n2dsy@hou2d.att.com (Internet)
           n2dsy@kd6th.nj.usa.hamradio.org.iso (Amateur Radio)
Telephone: +1.201.615.4168 (Office)   
           +1.201.615.4669 (Office FAX, include cover sheet with my extension)
           +1.201.387.8896 (Home)
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 19:03:50 GMT
From:      att!cbnewsd!pccl@ucbvax.Berkeley.EDU  (paul.c.liu)
To:        tcp-ip@nic.ddn.mil
Subject:   ping with data_size > 2020
Between Sun3 workstations running SUNOS 4.0.3, we were not able to
do ping commands with data_size greater than 2020 bytes, the frame
patterns were
 1514 icmp      echo
* 582 icmp 
 1514 icmp      echo reply
* 582 icmp 

However, from a UTS Amdahl, "ping +sv sun_3 4076 1" can be done and
etherfind shown
 1514 icmp      echo
*1514 icmp 
*1158 icmp 
 1514 icmp      echo reply
*1514 icmp 
*1158 icmp 

The ping source code indicated the maximum length of ICMP frame, MAXPACKET,
is 4096.  The error message on Sun3 when data_size of >2020 specified was
"sendto: Message too long".

Is this a ping bug on Sun workstations?  Any known fix available from netland?

Thanks in advance!

Paul.C.Liu@att.com
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 19:08:15 GMT
From:      sabre.bellcore.com!hjf@bellcore.com  (Henry J. Fowler Jr.)
To:        tcp-ip@nic.ddn.mil
Subject:   Congestion war stories
in data networks.   Examples of annoying problems of local impact,
as well as full-blown war stories of entire networks grinding to a halt
would all be of interest.
If you know of articles on this subject, or if you
have anecdotes to relate, I would really appreciate knowing about them.

Please send all replies directly to me.
If the information is useful, I will post
a summary to the group.  Thank you all in advance
for your assistance!

Henry Fowler
(201) 758-5667
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 19:57:40 GMT
From:      fernwood!portal!cup.portal.com!Will@apple.com  (Will E Estes)
To:        tcp-ip@nic.ddn.mil
Subject:   How Do Multiple Application Servers Interact With Transports?
I need help understanding how applications on a multi-tasking
server might interact with a transport protocol.  Most of the
transports that I have I been reading about seem to interact with
a machine ID and not a process ID.  What happens if you have two
different application or function servers (e.g., a Sun RPC server
and an Apollo RPC server) running on a single computer?  Is it up
to the message sender to imbed some identifier in the data that
lets each server know who the data is for?  Is it up to the server
application to go through each incoming message and decide whether
the message is for that server?  What are the different ways to
handle this problem?

Thanks,
Will              (sun!portal!cup.portal.com!Will)
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 20:43:00 GMT
From:      mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL")
To:        comp.protocols.tcp-ip
Subject:   RE: SRI-NIC.ARPA  IP NEEDED

Andrews AFB

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

                                        Date:     27-Apr-1990 04:34pm EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )


Subject: RE: SRI-NIC.ARPA  IP NEEDED


The attached Defense Data Network (DDN) Management Bulletin #72, 
dated 6 Apr 90, is provided for your information relating to the 
SRI-NIC.ARPA address and there New Network Addresses.  If you have 
any further questions, please call 1-800-235-3155, DDN Network 
Information Center and YES, they do help the INTERNET users.

Rodney A. McDaniel, DAFC
Information Systems Manager
Andrews AFB Md
Email: mcdaniel@hqafsc-vax.af.mil

*************************************************************************
DDN MGT Bulletin 72              DCA DDN Defense Communications System   
6 Apr 90                         Published by: DDN Network Info Center
                                     (NIC@NIC.DDN.MIL)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the NIC.DDN.MIL host [192.67.67.20]
using login="anonymous" and password="guest".  The pathname for
bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

                    NIC.DDN.MIL HOST ADDRESS CHANGE
                 AND ROOT DOMAIN SERVER ADDRESS CHANGE

In order for the NIC to provide better service, and because of the
phase-out of the ARPANET, the following changes have taken place and
are effective immediately (6 April 1990).

NIC.DDN.MIL
  The new address for host NIC.DDN.MIL is 192.67.67.20.

  The old ARPANET address for the NIC, 10.0.0.51, is no longer
  available, due to the phase-out of the ARPANET.

  The old MILNET address for the NIC, 26.0.0.73, will continue
  to be valid until 1 June 1990, after which service to this address
  will be discontinued.

ROOT DOMAIN SERVER
  The NIC's root domain server will run on a new host,
  NS.NIC.DDN.MIL at address 192.67.67.53.

  The old root server will continue to run on NIC.DDN.MIL
  until 1 June 1990.

New host tables and domain server files produced by the NIC will
reflect the new addresses.

Users should update host tables, domain server boot files, 
manuals, and documentation to reflect the new addresses.


The current list of root servers follows:

	   NS.NIC.DDN.MIL               192.67.67.53
	   A.ISI.EDU                    26.3.0.103
					128.9.0.107
	   AOS.BRL.MIL                  128.20.1.2
					192.5.25.82
	   C.NYSER.NET                  192.33.4.12
	   GUNTER-ADAM.AF.MIL           26.1.0.13
	   NS.NASA.GOV                  128.102.16.10
					192.52.195.10
	   TERP.UMD.EDU                 128.8.10.90
-------

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 21:24:09 GMT
From:      ssbell!weeks@uunet.uu.net  (John Weeks)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP & X.25 co-existence
In article <13936@nsc.nsc.com> balaji@nsc.nsc.com (Balaji Pitchaikani) writes:
>
>    1. All cards w/software donot support co-existence.Is this true?
>    2. What should he do to have X.25 and TCP-IP co-existence.
>    3. ARE ANY CARDS AVAILABLE With Software for VME Based (Dual Corp.)
>	    systems which support X.25 and TCP-IP.

CMC has a version of their ENP card that will run both X.25 and TCP-IP.  I'm
not sure what form factors are supported or the current availability, but
you could contact them for information.

                   Communication Machinery Corporation
                   125 Cremona Drive
                   Santa Barbara, Ca 93117

                   (805) 968-4262

-- 

John Weeks                                    Phone:  (402) 291-8300
Sterling Software IMD            e-mail: uunet!ssbell!weeks
1404 Ft. Crook Rd. South         e-mail: weeks@ssbell.IMD.Sterling.COM
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 23:22:04 GMT
From:      swrinde!cs.utexas.edu!ut-emx!walt.cc.utexas.edu!pmaniac@ucsd.edu  (Noah Friedman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <28764@ut-emx.UUCP> I wrote:
>In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>>... There are lessons to be learned, starting with the
>>abolishment of /etc/passwd and user access to the encryption
>>algorithm.
>
>I don't know that this is necessary. While it's possible that someone
>already has worked out a way to reverse DES, having access to
>/etc/passwd is quite useful. A number of my programs use information
>in this database, including the password field, so that other users
>can use their own passwords for various options while running my
>programs. 
>
>If DES is breakable, then a new algorithm needs to be implemented. And
>users should be encouraged to choose good passwords, otherwise it
>doesn't matter what encryption mechanism is used.

In response to this, someone sent me a message in Email claiming that he
could decrypt anything I gave him overnight. I sent him a reply, and sent
myself and one acquaintance a carbon copy, and neither one of us got the
carbon, so I assume neither did he. I also lost his address. Therefore,
here is a brief repost, with apologies to anyone who isn't interested.

Suppose you want to crack the password of some account using, say, the BSD
crypyt(3) algorithm. You can easily get the cyphertext from the /etc/passwd
file, and the salt used to encrypt the password (the first 2 characters of
the password field entry).

Now, for those who don't know, this string is not really the password. It's
a constant which was encrypted based on the key you entered. That constant
is usually '0', but some sites may change this for security. When a user
logs in, he types in his password. The computer takes this password and
crypts the standard constant, then compares the result to the crypted
string in /etc/passwd. If they match, the correct password must have been
typed in because crypt is a one-to-one function.

If the password is a good one (i.e. not part of the username, not listed in
/usr/dict/words, etc) then the only approach to cracking it is to try every
conceivable combination of characters.

Let's do a little math here. How many different types of characters are
allowable in a password? Not counting escaped control-characters, about
94 alphanumeric characters. There are a maximum of 8 characters in a
password, so the total number of permutations is
   
       94x94x94x94x94x94x94x94 = 94^8 (about 6.096x10^15)

The person who mailed me claimed he had about 50 workstations to play
around with (he did not say what kind). So lets have each workstation try 
1/50 of the total number of keys, which is

       (94^8)/50 = 1.219x10^14 keys/workstation

Of course, these computers can only do so many tries per unit time. Let's
suppose that each workstation can perform 100 crypt operations per second
(This is optimistic. My SPARCstation-1 can only do 20 per second with no
other load on it). Then the total time it will take to try all the possible
keys will be

      1.219x10^14 keys / (100 keys/second) = 1.219x10^12 seconds

Convert this time into years,
     
                      (1 minute)   (1  hour)   (1 day)      (1 yr)
    (1.219x10^12 s) x ---------- x --------- x --------- x ---------- 
                        (60 s)     (60 mins)   (24 hrs)    (365 days)

equals 38,658 years! Which is a little longer than overnight. :-)

(If I had 50 SPARCstations it would take them close to 200 thousand years
to try all the keys).

Of course, chances are you'll find the key long before then, but it could
still take hundreds or thousands of years, and the odds are against you
that you'll find it in your lifetime.

This is all academic, of course. There are far easier and faster ways of
breaking into a system than hacking passwords. But unless a deterministic
"anti-DES" algorithm has been developed, passwords are reasonably safe.
Someone with a hundred Crays each doing 1 million crypts per second would
still take 2 years, but few people have those kinds of resources.

---
Noah Friedman
pmaniac@ccwf.cc.utexas.edu
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 90 23:50:06 GMT
From:      usc!elroy.jpl.nasa.gov!zardoz.cpd.com!spsd!news@ucsd.edu  (Poorna Sreeramoju)
To:        tcp-ip@nic.ddn.mil
Subject:   UDP question


	PROBLEM is....

	In this UDP code example, I am trying to broadcast message
	so that all the other hosts on the same network can receive
	the same message, without server having to send multiple times.

	sendto() call fails with EADDRNOTAVAIL 59
	"Can't assign requested address"

	CODE SEGMENT is.....


	char			*name = "udpexample";
	int			s, ns, buflen, i, cc, pktsize;
	struct	sockaddr_in	*addr, addr_base, dst;
	struct	servent		*sp;
	struct	ifreq		ifr;


	sp = getservbyname(name, NULL);

	addr_base.sin_port		= sp->s_port;
	addr_base.sin_family		= AF_INET;
	addr_base.sin_addr.s_addr	= INADDR_ANY;

	s = socket(AF_INET, SOCK_DGRAM, 0);

	addr = &addr_base;
	bind(s, addr, sizeof(struct sockaddr_in));


	/*
		THIS BROADCAST CODE IS NOT WORKING
		WHY?
	*/

	ioctl(s, SIOCGIFBRDADDR, &ifr);

	dst.sin_port		= sp->s_port;
	dst.sin_family		= AF_INET;
	dst.sin_addr.s_addr	= 
		((struct sockaddr_in *) &ifr.ifr_broadcast)->sin_addr.s_addr;

	pktsize 	= atoi(argv[1]);
	buflen 		= sizeof(buf);
	memset(buf, '0', buflen);

	cc = sendto(s, buf, pktsize, 0, &dst, sizeof(dst));


	--------------------------------------------------------------------

	I used a SECOND METHOD which failed in a different way.

	Server will get its own internet address. It will then set rightmost
	byte to 255, to indicate broadcast address. Server was sending data
	this way. Then I started a client to receive from the host that the
	server is on. The receiver never gets anything. I tried setting right
	most 2 bytes to all 1's. It gave the same error as in ioctl, i.e.
	"Can't assign this address". We are using Class B type internet 
	addressing on 4.3 BSD compatible UNIX.


==============================================================================
poorna@irvine.dg.com
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 90 00:10:03 GMT
From:      uswat!matthews@boulder.colorado.edu  (John Matthews)
To:        tcp-ip@nic.ddn.mil
Subject:   Bridges Hanging & not passing bcasts

Can someone out there tell what the bug(s) is that causes Dec Lanbridge 100s
to to essentially stop passing broadcasts?  I remember hearing something
about this from someone but they never went into detail.  I remember reading
somewhere that a certain vendors bridge will stop passing broadcasts if
it gets a packet with a source address of ffff.ffff.ffff.  The bridge
sees this and then thinks of it as being a node and from then on it forgets
about forwarding it.  I remember it being something to do with MACs or PCs
when they're first booted.  We also have Retix bridges that do the exact
same thing.  If anyone has experienced similar problems with any vendors
bridge, please send me a note.  We are currently having to power cycle
these bridges every two or three days to clear up this problem.
					Thanks in advance,
						John Matthews
						matthews@uswat.uswest.com
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 90 05:50:42 GMT
From:      usc!elroy.jpl.nasa.gov!jarthur!jseidman@ucsd.edu  (James Seidman)
To:        tcp-ip@nic.ddn.mil
Subject:   Source for a basic UNIX ftp server

I am trying to set up a minimal-service FTP server to run on a non-standard
port to provide very limited transfer service.  Does anyone have any sample
code for a UNIX-based ftp server?  Also, does anyone know if RFC 532
actually has code, or is simply discussion?  It's not online at nic.ddn.mil,
and I don't want to send away for it without knowing what's really in it.
Thanks in advance.
-- 
Jim Seidman, Harvey Mudd College, Claremont, CA 91711.  (714) 621-8000 x2026
The Doctor: It was a terrible babble of inhuman voices.
Prof. Chronotis: Oh, that was just the undergraduates!
							- Doctor Who, "Shada"
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Apr 90 18:03:12 -0700
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        uunet!ucsd.edu!usc!elroy.jpl.nasa.gov!zardoz.cpd.com!spsd!news@uunet.UU.NET
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP question
> 	PROBLEM is....
> 
> 	In this UDP code example, I am trying to broadcast message
> 	so that all the other hosts on the same network can receive
> 	the same message, without server having to send multiple times.

[some code deleted for brevity ...]

> 	addr = &addr_base;
> 	bind(s, addr, sizeof(struct sockaddr_in));
> 
> 

/* Add the following code here */

{
	int on = 1;

	setsockopt (s, SOL_SOCKET, SO_BROADCAST, (char *) &on, sizeof (on));
}

> 	/*
> 		THIS BROADCAST CODE IS NOT WORKING
> 		WHY?
> 	*/
> 
> 	ioctl(s, SIOCGIFBRDADDR, &ifr);
> 
> 	dst.sin_port		= sp->s_port;
> 	dst.sin_family		= AF_INET;
> 	dst.sin_addr.s_addr	= 
> 		((struct sockaddr_in *) &ifr.ifr_broadcast)->sin_addr.s_addr;
> 
> 	pktsize 	= atoi(argv[1]);
> 	buflen 		= sizeof(buf);
> 	memset(buf, '0', buflen);
> 
> 	cc = sendto(s, buf, pktsize, 0, &dst, sizeof(dst));
> 

hwajin
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 90 20:23:46 GMT
From:      ucla-an!hermix!lance@RAND.ORG  (Lance Ellinghouse)
To:        tcp-ip@nic.ddn.mil
Subject:   132 column Telnets????
Has anyone ever written a Telnet that works with packet drivers
on DOS that will do 132 column??
NCSA? BYU? Anyone?

Where can I get it? How much? etc...

I am in desperate need of it (NCSA perferably so that I can have
multiple sessions at once).

Thank you very much!

(P.S. PLEASE respond to the following address and not the one
in the headers:
   hermix!unigold!lance@anes.ucla.edu

Thank you again for all your help!)

Lance Ellinghouse
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 90 20:30:47 GMT
From:      usc!samsung!sol.ctr.columbia.edu!ira.uka.de!fauern!fauern!eckert@ucsd.edu  (Toerless Eckert)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: /etc/hosts, DNS, sendmail.cf, YP ?
From article <9004201944.AA23924@ucbvax.Berkeley.EDU>, by 08071TCP@MSU.BITNET (Doug Nelson):

> 
> /etc/hosts should contain the fqdn as the first name for any entry.  You
> probably want to have the short form of the name as well for local hosts.

My experience is that there are several problems with using the fqdns
as the first names in the /etc/hosts file. The first name is the one
returned by gethostbyaddr(3), so with this setup you end up running the
machine completely with FQDN's. My idea about this is: either run
the machine with real DNS access (i.e.: resolver) or run it with short
names. Usually those machines that cannot be run with resolver have
problems with domainnames too. This is especially true for
domainnames longer than 32 chars, because 32 chars is the most common
length limitation in programs using hostnames (20 is the even worse one,
and 64/256 are the limitations proposed by the RFC's, that i've
seen in no software yet, beside the nameserver itself !).

>>2.) If I set up Domain Name Service I cannot provide short nicknames in
>>    other domains, so hacking ip-numbers would be easier to use
>>    telnet and ftp.
> 
> Not completely true.  You can define a list of domains to search in
> /etc/resolv.conf or its equivalent. ...

There is another alternative. One can create a file with abbreviations
for domainnames and have the environment variable HOSTALIASES point
to this file. I find this more appealing, because including 
domainname prefixes with /etc/resolv.conf will often result in
unwanted matches (especially for those names which happen to be used
in every other domain, .. marvin.domain.., sun.domain.., vax.doamin...)

>>    Some implementations do  not fall back to /etc/hosts if the
>>    nameserver has no answer. Am I missing something?
> 
> There has been discussion on this in the past; this is probably a good
> thing, since the DNS should have more accurate answers than the
> /etc/hosts file.  A bad answer can be worse than no answer, especially
> if you have an alternate query to try in the "no answer" case.

Right, to my knowledge only Ultrix allows you to configure this to
your taste.

>>    Again the question: UNIX-nodenames or fully qualified DNS-
>>    domainnames ?
> 
> Fqdn's, for sure.

Depends on how much hassle you want to stand. If the machine uses the resolver
you don't have the chance, as you get the hassle with FQDN's anyway.
Fields of attraction for FQDNS are ~/.rhosts, /etc/bootparams (on suns),
all other uses of FQDN's can be handled by introducing netgroups
containing the FQDNS (this is where YP is useful).

>>    What can I assume when they do a gethostbyname()? Will the answer
>>    come from YP, DNS, /etc/hosts or have I to set up a separate table
>>    for sendmail?
> 
> Gethostbyname will get answers from any/all of the above.  DNS should
> take precedence over /etc/hosts; I forget where YP fits in, but I would
> suggest installing a non-YP version of gethostbyname if you can.  Newer
> versions of sendmail (with MX support) do not normally call the standard
> gethostbyname, so they will strictly use the DNS.

Untrue, 5.61 uses gethostbyname(3), and it would be silly, not to.
If you have a chance to configure it (Ultirx), then of course bind
should be first (for true believers at least).

>>So the things seem to be complicate. I would like to give my users
>>some useful and short informations to set up their machines:
>>- if you want to use /etc/hosts only I'll give you a valid file,
>>- if you want to use DNS do the following (...)
>>- if you want to set up SMTP (no UUCP concerned here) I give you a
>>  general sendmail.cf,
>>    fill in your hostname
>>    fill in your (sub-)domainname and that's it,
>>- if you have YP running consider the following things (...)
> 
> That's much like what I try to do.  I direct people to use DNS
> where possible; I let the groups with YP solve their own problems,
> and tomorrow I'll work on a better sendmail.cf.....

Yes, it's not that difficult, sun's are somewhat complicated, because
the resolver library is not supported per se, so using the resolver on sun
is without support (i don't know about SunOS 4.1 though).

-- 

Toerless Eckert     Internet: eckert@informatik.uni-erlangen.de
                    X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 90 07:22:53 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!bunyip!cuscus.cc.uq.oz.au!ggm@tut.cis.ohio-state.edu  (George Michaelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Could MX <pref> be made to do more?

Take some host eg bunyip, a long way out on the edge of the Internet
western-galaxy-arm. it's primary relay for the rest of the world is
munnari.oz.AU, another host somewhat nearer the galactic core, but
still a long way out in the boondocks.

If bunyip is unable to SMTP reach munnari directly, but IS able to locate
MX records for it... then the next-preference hosts are all THE OTHER
SIDE of the fat pipe to the states. Since not being able to reach
munnari is semi-fatal for delivery beyond and into the promised land
this means.... your mail sits in the local queue.

In general, it looks like MX <pref> states what the Recipient host
views as its preferred relaying agents. This is NOT always the same as
"the best place to chuck this message at if you can't get to some
 better place" especially for poorly connected and remote members of
the network.

Ok, so this field is not up for re-interpretation. What can badly connected
hosts do to get round this?

I have tried tossing around in my head some ideas about calculating hop
counts and other things... they are all horrible. I am beginning to think
that MX is not "rich" enough to cope with two biggish networks colliding
via one fat pipe. My preferences for munnari's MX certainly wouldn't do
for anybody the other side of the water. I assert that their preferences
don't do much good for me neither. Looks like a relay host has to try and
tell different stories about MX depending on who asks. Is this feasible?

If it was, it would  would allow existing MX-lookup systems to work as per 
normal. Puts a lot of load on the source of the information, but only
at cache-refresh and lookup time. once you have a lie-MX in your DB its
just like normal.

I guess something which used some knowledge about the MX-requestors network
number and which ethernet interface a request comes in on might be enough.

Please put me straight.
	
	-George
--
	George Michaelson
Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD Australia 4067. 
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Apr 90 23:35:17 -0400
From:      tmallory@BBN.COM
To:        "paul.c.liu" <att!cbnewsd!pccl@ucbvax.berkeley.edu>
Cc:        tcp-ip@nic.ddn.mil, tmallory@BBN.COM
Subject:   Re: ping with data_size > 2020
Paul,

>Between Sun3 workstations running SUNOS 4.0.3, we were not able to
>do ping commands with data_size greater than 2020 bytes, the frame

We haven't had time to pin down the exact packet packet sequence with an
ethernet analyzer, but a similar situation in our lab with fragmented packets
exceeding 2000 bytes caused a Sun-3 to generate single (illegal!) ethernet
frames with lengths exceeding 4096 bytes.  The situation was complicated by an
intervening network with an artificially reduced MTU, and possibly other
factors.

The ability to send and receive Ethernet frames greater than 1514 bytes is a
feature of the AMD (and Thompson) LANCE chip.  For the time being, we fixed a
bug in our own Ethernet device driver in order to gracefully accept large
frames, and hope to get around to the Sun-3 at some future date.  Fixing it
isn't a high priority: how else can we generate such huge frames for test
purposes? ;-)

Tracy Mallory
BBNCC
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 90 21:56:31 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!seth@tut.cis.ohio-state.edu  (Seth Robertson)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/UDP IP forwarder & logger announcement

I recently hacked out a small(?) program that will forward TCP and UDP
packets.  It has quite a few options which basicly allow you to
specify whether the port will wait for you to connect to it or whether
it will try and talk to you.  Among other things, it can forward TCP
packets to UDP-land and vis-versa.

It can be used, among other things, to get accurate logs for performance
monitoring of, say, X11 (by logging the times of every packet).

The usual disclaimers apply (no responsibility for anything).

It is available for anonymous ftp from sol.ctr.columbia.edu
[128.59.64.40] along with a lot of other TCP/IP stuff (if you have
any other suggestions, let me know)


                                        -Seth Robertson
                                         seth@ctr.columbia.edu
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Mon 30 Apr 90 11:16:43-CDT
From:      Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
To:        tcp-ip@nic.ddn.mil
Cc:        ejw@derdmain.ed.ray.com
Subject:   Sendmail source request???

  I am posting this request for a friend:

	Does anyone have non-proprietary Unix sendmail source code?

  Please reply direct to ejw@derdmain.ed.ray.com
  Thanks in advance!

  >Matt
-------
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Apr 90 11:02:58 EDT
From:      fks@vax.ftp.com (Frances Selkirk)
To:        hermix!unigold!lance@anes.ucla.edu, tcp-ip@nic.ddn.mil
Cc:        fks@vax.ftp.com
Subject:   re: 132 column telnets????

The IBM 3270 emulator in our PC/TCP has a 132 column mode that works 
on VGA and some other display adapters. We do not yet have 132 column 
mode for the VT220 emulator, but we will be adding it. We do support
Interrupt 14 emulators by many other companies; some of these may have
132 column mode.

PC/TCP is available for the packet driver. The cost is $400 ($360 for
educational institutions) or $490 ($441 educational) with InterDrive,
our NFS client implementation. Site licenses are available.

				-Frances



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Frances Kirk Selkirk				        	 info@ftp.com
FTP Software, Inc.						(617) 246-0900
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Apr 90 14:03:50 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        ggm@cuscus.cc.uq.oz.au
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Could MX <pref> be made to do more?

> If bunyip is unable to SMTP reach munnari directly, but IS able to locate
> MX records for it... then the next-preference hosts are all THE OTHER
> SIDE of the fat pipe to the states. Since not being able to reach
> munnari is semi-fatal for delivery beyond and into the promised land
> this means.... your mail sits in the local queue.

Why are all the MX RRs on the wrong side of the pipe?? 

In general, your lowest MXs ought to be very close to your system.  So
if you miss munnari, you oughtta be getting an MX nearby.

I assume munnari is trying to suck mail on the far side of the link to
particular machines on the far side of the link that it knows have
better connectivity.  That's great (and what MX was primarily designed to
do) -- but we did consider the problem of finding your mail accidentally
going out over the link and back, and concluded having extra MXs locally
was the right answer.  [The logic goes something like this:  If a system
can't reach munnari, but can reach some host across the fat pipe,
we'd like to get across the pipe.  So we oughta have some MXs over
there.  Furthermore, if a host is already on munnari's side of the
fat pipe, we don't want stuff straying out if we can avoid it,
so again we'd like MXs near munnari.  If a system on the far side
of the pipe can't reach any MXs on munnari's side of the pipe, then
the pipe is probably down or unreachable from this system, and we will
forward to an MX on the US side of the pipe].

Craig
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 90 12:01:47 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!enea!mats@ucsd.edu  (Mats Josefsson)
To:        tcp-ip@nic.ddn.mil
Subject:   The best TCP/IP implementation to base a port on?
We're in the process of implementing the TCP/IP protocol suite on a
Motorola 680x0 based system. It is running a Real-Time Operating
system radically different from Unix (more about that below).

The functionality we need are ARP/RARP, IP, TCP and UDP. Our system
will communicate with Unix systems over Ethernet so the TCP/IP
software should be standard conforming. Our TCP/IP implementation will
also need to be able to route IP traffic.

It should be possible to boot our system from a Unix host over
Ethernet (this will require a minimal implementation of ARP/RARP,
BOOTP and TFTP, right?).

We are also looking for an X.25 implementation so that we can run IP
over a X.25 PDN.

To save time (and money) we are planning to base our implementation on
an already existing implementation written in C.  The software is to
be incorporated in a commercial software package so we must be able to
get the rights to use and sell the software.  We would of course be
prepared to pay for the use of a commercial product.

My questions are the following:

1. Which TCP/IP implementation would be the best to start from? My
   understanding is that we could use the 'BSD 4.3-Tahoe'
   implementation. It is free (with some restrictions), implements
   most of the required functionality, and it is widely used. I'm sure
   there are several other alternatives.

2. Is there anyone who has done a port like this before. I would be
   interested to get an indication of how much time it should take,
   and any other relevant information.

3. Does anyone know of a X.25 implementation that we could use?

The Real-Time OS we are using supports processes with hard
priorities, messages between processes, shared memory, semaphores,
timers, interrupt handlers etc.  It is very fast. Process switch and
message sending takes about ten microseconds (on a 25 MHz MC68020).

This makes me believe that the TCP/IP package could be made to run as
user processes and structured more or less like the layers in the OSI
model, with two processes handling each level (one for input and one
for output). At the  user level it should be possible to implement a
TLI-like procedure interface library. 

I would be grateful for any information that would help. Information
(technical and pricing) from vendors with suitable products would also
be welcome.

Please reply by mail, or post if You think it's of general interest.
I'll post a summary if there is interest. 

Regards,

Mats Josefsson (mats@enea.se)
Enea Data AB
Box 232
S-183 23 TABY
SWEDEN
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 90 12:20:44 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!ncs.dnd.ca!jstewart@ucsd.edu  (John Stewart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Bridges Hanging & not passing bcasts
In article <7558@uswat.UUCP> matthews@uswat.uswest.com (John Matthews) writes:
>
>Can someone out there tell what the bug(s) is that causes Dec Lanbridge 100s
>to to essentially stop passing broadcasts?  I remember hearing something
>about this from someone but they never went into detail.  I remember reading
>somewhere that a certain vendors bridge will stop passing broadcasts if
>it gets a packet with a source address of ffff.ffff.ffff.  The bridge
>sees this and then thinks of it as being a node and from then on it forgets
...

I once managed a network tied together with 5 lanbridge 100's. I had a
problem that caused a Vax running Wollongong to stop listening to ARP's
from Sun workstations.

The long and the short of it was that I wrote an ethernet monitor (no
money for a real one), and I got the following packet:


** Packet #1 **
Source:       FF FF FF FF FF FF	General Purpose multicast
Destination:  FF FF FF FF FF FF	General Purpose multicast
Protocol:    FFFF	Not a defined protocol type
	
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 	................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 	................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 	................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 	................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 	................
FF FF FF FF FF FF 00 01 00 00 00 0A 00 00 00 00 	................
00 00 00 00 00 00 0A 03 00 00 00 01 00 08 00 00 	................
1E 96 32 D0 66 4B 00 00 00 08 00 00 1A 3F 08 1A 	..2PfK.......?..
DA 28 00 00                                     	Z(..

Obviously not a valid packet! I found this by using dec's lanbridge
managament package, seeing what was found on each side of all the
bridges. I also had a spare bridge, which helped alot, as I could
move thinwire segments around and thus isolate a segment.

It ended up that a sun workstation was pumping the above packet out
once or twice per day.

It's been a while since I posted the above, and I forget the details
of exactly what versions of lanbridges did what (it did make a
difference, though), and exactly what the RBMS software displayed
when a bridge found the ff.ff.ff.ff.ff.ff. 

Your synopsis of the problem is correct. You need to see what is on
the bridges to find out which half of the bridge sees the broadcast.

Good luck!

John Stewart.
jstewart@crc.skl.dnd.ca.
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Apr 90 09:49:15 +0200
From:      pansiot%isis.u-strasbg.fr@CUNYVM.CUNY.EDU (Jean-Jacques Pansiot Departement d'Informatique, Universite Louis Pasteur Strasbourg FRANCE)
To:        tcpipl@UNKNOWN.DOMAIN
Cc:        crc@UNKNOWN.DOMAIN
Subject:   rlogin and security

I know that rlogin is not secure, but its worse than what i thought.
Basically with rlogin anybody can break into your computer (at leasr Sun,
Silicon Graphics,...) provided you have entries in your /etc/passwd with
*  as a password. I thought * was used to forbid login, it is quite the
contrary.
Is this a well known Bug of rlogin?  Is there a Fix ?

Jean-Jacques Pansiot , Universite de Strasbourg, France

pansiot@isis.u-strasbg.fr
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 90 16:44:38 GMT
From:      anagld!rcsmith@uunet.uu.net  (Ray Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet connectivity for a 286/Multibus 1 XENIX system

   I am new to the XENIX world (although I have been playing in UNIX for
a while) so please bear with me if this has been brought up before.

   I recently took on the responsiblity of a whole lot of '286/Multibus 1
based systems running Intel XENIX.  I am interested in hooking these up to
our ethernet lan.  Naturally I would like the product to be based on
TCP/IP protocols with utilities such as ftp and telnet.  SMTP would be
nice to have as well.  Is anyone aware of any products, hardware and
software, to do this?

Thanks in advance,
Ray
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
        Ray Smith         | UUCP: {uunet,aplcen,sundc}!anagld!rcsmith
     Analytics, Inc.      | ARPA: rcsmith@analytics.com or
        Suite 200         |       anagld!rcsmith@uunet.uu.net or
 9891 Broken Land Parkway |       RCSmith@DOCKMASTER.NCSC.MIL
    Columbia, MD 21046    | Voice: (301) 381-4300         Fax: (301) 381-5173
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 90 18:03:50 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Could MX <pref> be made to do more?


> If bunyip is unable to SMTP reach munnari directly, but IS able to locate
> MX records for it... then the next-preference hosts are all THE OTHER
> SIDE of the fat pipe to the states. Since not being able to reach
> munnari is semi-fatal for delivery beyond and into the promised land
> this means.... your mail sits in the local queue.

Why are all the MX RRs on the wrong side of the pipe?? 

In general, your lowest MXs ought to be very close to your system.  So
if you miss munnari, you oughtta be getting an MX nearby.

I assume munnari is trying to suck mail on the far side of the link to
particular machines on the far side of the link that it knows have
better connectivity.  That's great (and what MX was primarily designed to
do) -- but we did consider the problem of finding your mail accidentally
going out over the link and back, and concluded having extra MXs locally
was the right answer.  [The logic goes something like this:  If a system
can't reach munnari, but can reach some host across the fat pipe,
we'd like to get across the pipe.  So we oughta have some MXs over
there.  Furthermore, if a host is already on munnari's side of the
fat pipe, we don't want stuff straying out if we can avoid it,
so again we'd like MXs near munnari.  If a system on the far side
of the pipe can't reach any MXs on munnari's side of the pipe, then
the pipe is probably down or unreachable from this system, and we will
forward to an MX on the US side of the pipe].

Craig

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 90 21:32:57 GMT
From:      motcid!yu@uunet.uu.net  (Kimberly Yu)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP agent software for Sun
straw@cam.nist.gov (Mike Strawbridge) writes:

>I am looking for available SNMP agent software for 4.3 BSD UNIX ...
>specifically Suns. 

>I would like to hear about all commercial and public domain SNMP packages
>that run on Suns. I would especially like to hear from you if you have
>experience with any of these.

>I am not only interested in managing a TCP/IP network with a Sun. In our
>case a Sun may be a managed device on the network (i.e. a Sun acting a
>router between subnets).

>Thanks.

>-----------------------------------------------------------------------
>NAME:   Michael Strawbridge             	TELE: (301) 975-3852
>USMAIL: National Institute of Standards 	ARPA: straw@cam.nist.gov
>		and Technology            	UUCP: uunet!cme-durer!straw
>        Rm. B-146, Bldg. 225
>        Gaithersburg, MD  20899
  
Recently I got the SunNet Manager but I haven't installed on our Sun net.
I am try to get some info/opinion from someone who have experienced in 
these.  I would also like to hear about available SNMP packages.  
Would you please forward the information to me (if you get any).
thanks

e-mail :  motcid!yuk@uunet.uu.net
          phone #(708) 632-5397

Kimberly 
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 90 22:43:36 GMT
From:      uswat!matthews@boulder.colorado.edu  (John Matthews)
To:        tcp-ip@nic.ddn.mil
Subject:   Bridges not passing bcasts (update)
I've gotten at least ten responses so far stating that my suspicions
about the LanBridge100s learning bad source addresses were correct.
A couple of people that responded expressed interest in knowing about
any/all bad software and hardware that sends packets with a source
address of FFFF.FFFF.FFFF.  In addition, I myself would also like to
know of any other hardware or software that transmits any kind of random
packet.  I had one response that stated that PC-NFS 3.0 sent out these
bad packets.  Another person said that they had a SUN that would send out
one or two of these bad packets per day.  If anyone one else has seen
other hardware/software do this, please respond.  Please give a little
detail if possible.  What other bridges does everyone know about that
learn these bad source addresses?
                                        Thanks in advance,
                                                John Matthews
                                                matthews@uswat.uswest.com

END OF DOCUMENT