The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for June 1990 (495 messages, 294957 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/06.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 Jun 90 00:35:40 GMT
From:      [email protected]  (Dan Lanciani)
To:        [email protected]
Subject:   Re: Dial up access to Internet facilities
In article <[email protected]>, [email protected] (Kent England) writes:
> In article <[email protected]>, [email protected]
> (Jon Bloom) writes:
> > In article <[email protected]>, [email protected] (Kent England) writes:
> > > We also have strict standards on quality of service, and we
> > > do not wish to compromise these standards in offering less costly access,
> ...
> 	All this adds up to quite a chunk of change.  Makes UUCP look pretty
> good, eh?      :-)

	One of the reasons that UUCP does indeed look good in this comparison
is that the current structure of UUCP networks (last I looked!) still allows
a site to join the network at as low a cost and with as poor service as it
can tolerate.  In many cases, e.g., a local phone call, that service can
be pretty good and pretty cheap.
	Many regional internet service providers forbid "third party"
connections and nets-behind-nets because they see such access as depriving
them of the revenue they would obtain from a directly-connected customer.
While this may be a valid business concern, and while it has the side effect
of allowing the regional to enforce a certain quality of service, it can
preclude some interesting and potentially cost-effective (at least for the
customers) structures.
	A more standard and quantitative method of charging for internet
service, e.g., per-packet accounting (sigh), might allow the existence of
low-end sub-service providers without threatening the income of the regionals.
That is, a regional need not worry whether two customers pay for 100
packets each or one subcontractor pays for 200.  Competition could then
drive the price of service down to a point where even an individule can
afford a connection...

				Dan Lanciani
				[email protected]*
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 09:17:08 PDT
From:      [email protected]acc.com (Art Berggreen)
To:        [email protected]
Cc:        [email protected]
Subject:   Re: Duplicate packets in Internet.
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Duplicate packets in Internet.
Summary: 
Expires: 
References: <[email protected]>
Sender: 
Reply-To: [email protected] (Art Berggreen)
Followup-To: 
Distribution: na
Organization: Advanced Computer Communications, Santa Barbara, California
Keywords: 

In article <[email protected]> [email protected] (Dheeraj Sanghi) writes:
>
>I wonder if people have noticed duplicate IP packets in
>any study. Is there any possibility of duplication apart
>from because of some bug in the gateway software?

The most common source would be from unneccessary transport level
retransmissions.  This is usually due to rapid build up of congestion.
This is aggravated by non adapting retransmission strategies.
The most famous situation is the "congestion collapse" first described
(I believe) by Nagle.

>Any pointers in this regard would be much appreciated.
>
>Thanks,
>
>-dheeraj
>
>--
>Dheeraj Sanghi			(h):301-794-6247	(o):301-454-1516
>Internet: [email protected]	UUCP: uunet!mimsy!dheeraj
>If you want to judge the culture and civilization of a people you can find
>that out by the status and conditions of the women of the country. - Nehru

Art Berggreen
ACC

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 02:56:22 GMT
From:      [email protected]  (Dheeraj Sanghi)
To:        [email protected]
Subject:   Duplicate packets in Internet.
I wonder if people have noticed duplicate IP packets in
any study. Is there any possibility of duplication apart
from because of some bug in the gateway software?

Any pointers in this regard would be much appreciated.

Thanks,

-dheeraj

--
Dheeraj Sanghi			(h):301-794-6247	(o):301-454-1516
Internet: [email protected]	UUCP: uunet!mimsy!dheeraj
If you want to judge the culture and civilization of a people you can find
that out by the status and conditions of the women of the country. - Nehru
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 02:57:18 GMT
From:      [email protected]  (John Chambers)
To:        [email protected]
Subject:   Re: Dealing with systems without nameservice.
In article <[email protected]>, [email protected] (Doug Nelson) writes:
> From Stan Stead:
> >        We are running 4.3 BSD.  We currently use nameservice.  However,
> >a site that we wish to exchange mail and files, while connected to the
> >internet, does not use nameservice.  We can access the site by internet
> >number, but not by name.  Is there anyway to "hot-wire" an address
> >(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
> >is if named is not running.
> 
> The real answer is for them to set up name service.  I can't think of
> any good reason for sites attached to the internet to not be running
> name service, or to find a site that can run name service for them.

Gee, I can think of several reasons off the top of my head.  For instance,
I'm working in a network testing lab in which we are constantly fiddling
with the wiring, setting up new networks for a few hours, interconnecting
them at random, changing host names and IP addresses, and all the other
things you need to do to test stuff.  It's not even vaguely reasonable
to expect a nameserver administrator to keep track of all our fiddlings,
and usually we only tell them about the couple of "main" machines that
hold the source, or where we want to send/receive mail.  The rest we take
care of by editing /etc/hosts as needed.

An example of how difficult things can be is our couple of DOS machines
with tcp/ip.  They don't have a local hosts file, and must get all addresses
from a nameserver.  The result is that tests on DOS are *much* slower, since
we must go through a nameserver, which means telnetting to the nameserver,
editing files, and all that.

Another nameserver gotcha turned up a couple of months ago, when people
decided to rename and renumber all of the "main" machines in the lab.
The nameserver had the wrong IP address (two digits interchanged) for
the mainest of the machines (the one with all the source on it), and 
it took about a month to persuade the (badly overworked) administrator
of the nameserver to correct the typo.  /etc/hosts came in very handy
during this period.

Yeah, I know, these are all pathological cases that "shouldn't happen"
to many users.  My main response to that sort of criticism is that I've
never yet worked on a machine that wasn't unusual in some major respect.
(I keep looking for one; I assume they must exist somewhere... ;-)  If
you want to get your job done, you often have to find ways around all 
the broken software, and nameservers are often broken with respect to
some subset of the machines on the network.  So you use it if you can,
and learn to live without it when you must.

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 03:28:36 GMT
From:      [email protected]  (Stuart Lynne)
To:        [email protected]
Subject:   Re: Dial up access to Internet facilities
In article <[email protected]> [email protected] (Dan Lanciani) writes:
>While this may be a valid business concern, and while it has the side effect
>of allowing the regional to enforce a certain quality of service, it can
>preclude some interesting and potentially cost-effective (at least for the
>customers) structures.
>	A more standard and quantitative method of charging for internet
>service, e.g., per-packet accounting (sigh), might allow the existence of
>low-end sub-service providers without threatening the income of the regionals.

It also provides a way for people to try things out. A sys admin can hook
into van-bc for example simply by agreeing to attempt to make some donations
to help us run things. So he can hook up, usually with existing resources
and then after a few months demonstrate to management that it's a good
thing. And then get authorization to do it and make some donations.

We also see people using the uucp service for a while and then deciding to
move up into SLIP service directly into the regional network. Again if they
hadn't had the opportunity to demonstrate the usefullness of the endeavour
they might not have been able to get management approval for the more
expensive regional network connection. 

-- 
[email protected] ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 08:35:01 EST
From:      bill gunshannon <702WFG%[email protected]>
To:        [email protected]
Subject: Re: tcp/ip services <--> decnet connectivity, help wanted
>>The easiest thing to do would be to get a DECstation 3100 (or something
>>else running Ultrix) and use the DECnet-Internet gateway software. I
>
>I also spent a long time looking for a TCP/IP implementation for RSTS.
>After giving up on that, I looked at the solution described above, i.e.
>an Ultrix VAX as a gateway.  All you need to run on it is DECnet-Ultrix.
>This automatically does conversion between DECnet protocols and TCP/IP
>protocols (according to DEC). Get DEC's "Local Area Network Solutions
>Guidebook" and read page 74.

While this sounds like an easy solution, it may not really be so.  I have a
DECstation 3100 sitting here in front of me and I can assure you that it did
not come with any of the DECNET software.  I assume DECNET is an option and
based on the cost of the box alone, if you have to pay extra for the software
too, it's an awful expensive solution.

                                          bill gunshannon
                                       [email protected]

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 10:29:58 -0400
From:      Frank Solensky <solensky%[email protected]>
To:        MAINT%[email protected]
Cc:        [email protected]
Yes, it is atypical.  I've been on the list for about a year and this is the
first time someone at, shall we say, "this level" (note indiscriminate use
of "O" and "0") has posted this type of thing.
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 11:14:31 PDT
From:      [email protected]
To:        [email protected], [email protected]
Subject:   Re:  Duplicate packets in Internet.
Dheeraj:

Just run "ping" thru any NSS.  You get back more echo-replies than
echo-requests you sent.  Somebody is duplicating something somewhere.

--jon.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
% ping lcs.mit.edu
PING lcs.mit.edu: 56 data bytes
64 bytes from 18.26.0.36: icmp_seq=0. time=499. ms
64 bytes from 18.26.0.36: icmp_seq=1. time=360. ms
64 bytes from 18.26.0.36: icmp_seq=1. time=360. ms
64 bytes from 18.26.0.36: icmp_seq=2. time=340. ms
64 bytes from 18.26.0.36: icmp_seq=3. time=320. ms
64 bytes from 18.26.0.36: icmp_seq=4. time=360. ms
64 bytes from 18.26.0.36: icmp_seq=5. time=400. ms
64 bytes from 18.26.0.36: icmp_seq=5. time=440. ms
64 bytes from 18.26.0.36: icmp_seq=6. time=339. ms
64 bytes from 18.26.0.36: icmp_seq=6. time=339. ms
64 bytes from 18.26.0.36: icmp_seq=7. time=380. ms
64 bytes from 18.26.0.36: icmp_seq=8. time=340. ms
64 bytes from 18.26.0.36: icmp_seq=9. time=340. ms
64 bytes from 18.26.0.36: icmp_seq=10. time=380. ms
64 bytes from 18.26.0.36: icmp_seq=10. time=440. ms
64 bytes from 18.26.0.36: icmp_seq=11. time=340. ms
^C
----lcs.mit.edu PING Statistics----
12 packets transmitted, 16 packets received, -33% packet loss
round-trip (ms)  min/avg/max = 320/373/499
% 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 12:16 MST
From:      JOHN BOREN <[email protected]>
To:        TCP-IP%[email protected]
Subject:   REMOVE
REMOVE me from your list. Someone else got me on it and I dont want to be

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 09:35:46 EDT
From:      Pete Hickey <[email protected]>
To:        [email protected]
Subject:   Re: LanTastic NOS and TCP/IP
Lantastic is Netbios based.  Wolongong's (sp?) product should run on
it, since it can put IP on netbios.  We have a Lantastic network
and may try that soon.

=======================================================================
Pete Hickey                     | This .signature is different from my
University of Ottawa            | old one, because rules say that it
Ottawa, Ontario, CANADA         | must be changed periodically.
(613) 564-7646                  |_____________________________________
    [email protected]      [email protected]
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 12:34:51 -0400
From:      "Martin Lee Schoffstall" <[email protected]>
To:        [email protected] (Dan Lanciani)
Cc:        [email protected]
Subject:   Re: Dial up access to Internet facilities
 	Many regional internet service providers forbid "third party"
 connections and nets-behind-nets because they see such access as depriving
 them of the revenue they would obtain from a directly-connected customer.
 While this may be a valid business concern, and while it has the side effect
 of allowing the regional to enforce a certain quality of service, it can
 preclude some interesting and potentially cost-effective (at least for the
 customers) structures.

Revenue is only one issue, there are considerations of performance,
debugging, responsability and market perception:

PERFORMANCE:
	There are cutomers who opt for 9.6-19.2 Internet connectivity,
	who don't understand why their link is unusable after they
	feed a couple fortune 500 companies with UUCP behind it, then
	potentially they want to offload their DNS to their service
	provider, which most regionals do, but why do we do it, for them or
	for the companies behind them which we have no relationship with.

DEBUGGING:
	So the MX record doesn't work, so their sendmail.cf is misconfigured
	in doing this, so the side behind them calls the service
	provider to ask questions, get help, whatever.  For the
	regionals working with each other all the time, the  RIGHT
	assumption is that everyone is carrying each other at some
	level, and that the people at the ends are paying for
	the service.  A terminus uucp connection (which is the
	norm for the problem sites), pays nothing.

RESPONSABILITY:
	Who is responsible for that uucp connection, especially when
	friend system administrator A and University B moves onto
	make some big money at Commercial company C.

MARKET PERCEPTION:
	Maybe this is the largest issue of all, without even trying
	the service quality perception of network Z can be drawn
	down by a dozen bad uucp connections who's users think
	they are on ZNet and they tell their friends about how
	it isn't reliable, doesn't work, poor performance etc...


Some organizations including PSI/PSINet throughout the US and
CERFNet throughout California have simply decided that the
real solution is to establish local dialups everywhere they
are, and provide CHEAP UUCP connections and deal with this
directly.

Marty
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 07:43:48 GMT
From:      eru!luth!sunic!mcsun!hp4nl![email protected]  (Marcel Bernards)
To:        [email protected]
Subject:   SLIP source wanted for HP9000/340
Hello NetReaders,

I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5 / 7.0.

We already got SLIP stuff for BSD/SUNOS based machines, but they cannot be
ported easily on HP's. Is there someone who has it or where I can FTP
the stuff ?? 

Please E-mail

Thanx in advance

Greetings,

-- 
Marcel Bernards, UNIX & Net sysadm Netherlands Energy Research Foundation ECN
P.O. Box 1, 1755 ZG Petten, PHONE: 09 312246 4579 EARN/BITNET:[email protected] 
EMAIL: [email protected] bernards%[email protected]{nluug.nl,uunet.uu.net},hp4nl!ecn!bernards
SCREAMNet : AAAAAARGHH!HUH?? : Disclaimer: "The AntiChrist is the Computer !" 
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 11:56:15 EDT
From:      [email protected] (John A. Shriver)
To:        [email protected]
Cc:        [email protected]
Subject:   trash message from usenet (BIFF)
Actually, that message came in from usenet netnews.  It appears that
is was sent to every netnews mailgroup.  Dial-up access had nothing to
do with it.  (Anyone can send mail wherever they please from an
account anywhere on the Internet, and realistically, from anywhere in
usenet as well.)

The problem is the absolute complete and total lack of any sort of
security, trackability, or accountability in the netnews system that
runs on usenet (uucp) and over nntp.  The problem is that most of the
Internet mailing lists have been "gatewayed" to netnews mailgroups.  I
don't think that this was a good thing to do.  I don't like seeing
Internet mailing lists being brought down to the low level typical of
some of the netnews mailgroups.  I'd rather the "gateways" be made one
way (out from Internet only), or even non-existent.  (One could argue
that those "gateways" violate the access rules for the Internet, since
they cannot verify that the message came from an authorized user of
the Internet.)

I realize that this would deny netnews/uucp only sites access to the
Internet mailing lists, but if their umbrella organization (usenet)
cannot maintain professional standards of behavior, then that is their
loss.  By implementing a system without accountability, they create
that risk.

Another problem due to "gatewaying" has been consistent recurring
problems with mail loops through netnews.  About once a month one or
another of the mailing lists I'm on gets into a mail loop through
netnews.

I (and others) would welcome netnews being made properly accountable
and secure.  It is not, per-se, evil, and I understand that it is
efficient.  However, not building the Received: lines may make netnews
more efficient, but this removes all vestiges of accountability.  This
is a key problem.

The TCP-IP list has been quite consitently professional in its
conduct, as have most public Internet mailing lists.  Everything
unprofessional I have seen recently was "gatewayed" in from netnews.
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 13:17:34 CDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
In-Reply-To:  jas AT proteon.com   -- Fri, 1 Jun 90 11:56:15 EDT

John has made serveral good points but I was not aware that there was any
single point of contact for internet. I guess I thought anyone with sufficient
funds could connect to the internet. I guess part of the fault lies in the
apparent fact that there is no accountability requirement for internet
connections.

In any case it seems that the problem could be partly solved by the listserv
software itself. Simply reject any messages that do not have verifiable
Received: lines built. That wouldn't stop messages to non-listserv users but
those don't get distributed to hundreds of users. If the netnews folks want
their users to access internet lists then they can build Received: lines. If
they don't care then forget leave it the way it is. This type of problem is
cured in any event.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 08:38:00 GMT
From:      cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.[email protected]tut.cis.ohio-state.edu  (Don Lewis)
To:        [email protected]
Subject:   Re: Dealing with systems without nameservice.
In article <[email protected]> [email protected] (John Chambers) writes:
>In article <[email protected]>, [email protected] (Doug Nelson) writes:
>> From Stan Stead:
>> >        We are running 4.3 BSD.  We currently use nameservice.  However,
>> >a site that we wish to exchange mail and files, while connected to the
>> >internet, does not use nameservice.  We can access the site by internet
>> >number, but not by name.  Is there anyway to "hot-wire" an address
>> >(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
>> >is if named is not running.
>> 
>> The real answer is for them to set up name service.  I can't think of
>> any good reason for sites attached to the internet to not be running
>> name service, or to find a site that can run name service for them.
>
>Gee, I can think of several reasons off the top of my head.  For instance,
>I'm working in a network testing lab in which we are constantly fiddling
>with the wiring, setting up new networks for a few hours, interconnecting
>them at random, changing host names and IP addresses, and all the other
>things you need to do to test stuff.  It's not even vaguely reasonable
>to expect a nameserver administrator to keep track of all our fiddlings,
>and usually we only tell them about the couple of "main" machines that
>hold the source, or where we want to send/receive mail.  The rest we take
>care of by editing /etc/hosts as needed.

You could just create a "lab" subdomain and designate one of your
local machines as the server.  That way you don't have to bother
your overworked nameserver administrator (and you contain the damage).
Editing the zone files isn't that much harder than editing /etc/hosts,
and you don't have the bother of having to propagate the /etc/hosts
around, or do you just just use IP addresses everywhere.

>
>Another nameserver gotcha turned up a couple of months ago, when people
>decided to rename and renumber all of the "main" machines in the lab.
>The nameserver had the wrong IP address (two digits interchanged) for
>the mainest of the machines (the one with all the source on it), and 
>it took about a month to persuade the (badly overworked) administrator
>of the nameserver to correct the typo.  /etc/hosts came in very handy
>during this period.

Well, what if you sent your new (incorrect) /etc/hosts out all your
friends on the internet.  How much of a bother would it be to them
to have to incorporate this into their /etc/hosts files, and then
turn around and correct it.  And how much time is someone who missed
the correction (and someone at your end) going to spend debugging the
problem a six months from now when mail won't go through.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  [email protected]     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 13:41:45 EDT
From:      Bob Stewart <[email protected]>
To:        [email protected], [email protected], [email protected]
Subject:   Special purpose Host Requirements WG Formed
Hi,

    This is to announce the creation of an IETF working group (WG) to apply the
host requirements RFCs to special purpose hosts.  See the attached preliminary
WG charter for more information.

	Bob Stewart
	Chair, IETF Special-purpose Host Requirements WG

--------
Special-purpose Host Requirements Working Group

Chairman:

	Bob Stewart/Xyplex  [email protected]

First Meeting:

	August, 1990

Mailing Lists:

	General discussion:  [email protected]
	To subscribe:        [email protected]

Description of Working Group:

	The Special-purpose Host Requirements working group is chartered to
clarify application of the Host Requirements RFCs (1122 and 1123) to systems
that are technically hosts but are not intended to support general network
applications.  These special-purpose hosts include, for example, terminal
servers (a "Telnet host"), or file servers (an "FTP host" or an "NFS host").

	The Host Requirements RFCs address the typical, general-purpose system
with a variety of applications and an open development environment, and gives
only passing consideration to special-purpose hosts.  As a result, suppliers
of special-purpose hosts must bend the truth or make excuses when users
evaluate their products against the Requirements RFCs.  Users must then decide
whether such a product is in fact deficient or the requirements truely do not
apply.  This process creates work and confusion, and undermines the value of
the RFCs.  The commercial success of the Internet protocols and their use in
increasingly unsophisticated environments exacerbates the problem.

	The working group must define principles and examples for proper
functional subsets of the general-purpose host and specifically state how such
subsets affect the requirements.  The working group must determine the balance
between an exhaustive list of specific special-purpose hosts and philosphy
that remains subject to debate.  For the most part, it should be possible to
base decisions on existing experience and implementations.  The
special-purpose requirements will be stated as differences from the existing
RFCs, not replacements, and will refer rather than stand alone.

	Since they define strict subsets of the Host Requirements RFCs, the
Special-purpose Host Requirements appear to be an easier job and can be
developed and stabilized within 8-12 months.  Most of the group's business can
be conducted over the Internet through email.

Goals and Milestones:

1.  July 1990:  mailing list discussion of charter and collection of concerns.

2.  August 1990: First IETF Meeting: discussion and final approval of charter;
    discussion and agreement on approach, including models, format, level 
    and type of detail.  Make writing assignments.

3.  October 1990:  First draft document.

4.  November 1990:  Second IETF Meeting:  review first draft document, 
    determine necessary revisions.  Follow up discussion on mailing list.

5.  January 1991:  Revised document.

6.  February 1991:  Third IETF Meeting:  make document an Internet Draft.  
    Continue revisions based on comments received at meeting and over e-mail.

7.  April 1991:  Final draft document.

6.  May 1991:  Fourth IETF meeting:  review final draft and if OK, give
    to IESG for publication as RFC.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 14:38:16 EDT
From:      Doug Nelson <08071TCP%[email protected]>
To:        Dheeraj Sanghi <[email protected]>, "TCP/IP list (plus more)" <[email protected]>
Subject:   Re: Duplicate packets in Internet.
>I wonder if people have noticed duplicate IP packets in
>any study. Is there any possibility of duplication apart
>from because of some bug in the gateway software?

I believe the NSFNet routers (NSS's) are the (primary?) culprit.
It's not clear that this is a bug - it can happen from a link level
retransmission.  Recall that any given retransmission algorithm can
result in either duplicated data or dropped data.  In general, IP
routers will drop data, but sometimes IP packets travel over various
strange and wonderful routes.  I think that X.25 is one of those
protocols that will duplicate data rather than drop it.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 12:52:31 GMT
From:      [email protected]io-state.edu  (David N. Blank)
To:        [email protected]
Subject:   looking for netwatch in all the wrong places
Greetings-
  I recently attempted to ftp netwatch from watcom (as directed by a
past poster to here and/or comp.archives) but it seems to be an
incomplete package.  There is no setup doc, despite the setup program
"config".  Could a kind soul out there point me to a more complete source of
documentation for the package that would give me a clue on how to
make this puppy work?  Thanks muchly in advance.
         Peace,
            dNb
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 17:12:22 EDT
From:      [email protected] (Frances Selkirk)
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re:  trash message from usenet (BIFF)
The proper thing to do with babble is ignore it. The discussion about
one juvenile message has multiplied the wasted bandwith by six.

							(IMHO, oc.)

								-Frances

(Speaking for myself.)
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 13:35:01 GMT
From:      [email protected] (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   (none)
Subject: Re: tcp/ip services <--> decnet connectivity, help wanted
>>The easiest thing to do would be to get a DECstation 3100 (or something
>>else running Ultrix) and use the DECnet-Internet gateway software. I
>
>I also spent a long time looking for a TCP/IP implementation for RSTS.
>After giving up on that, I looked at the solution described above, i.e.
>an Ultrix VAX as a gateway.  All you need to run on it is DECnet-Ultrix.
>This automatically does conversion between DECnet protocols and TCP/IP
>protocols (according to DEC). Get DEC's "Local Area Network Solutions
>Guidebook" and read page 74.

While this sounds like an easy solution, it may not really be so.  I have a
DECstation 3100 sitting here in front of me and I can assure you that it did
not come with any of the DECNET software.  I assume DECNET is an option and
based on the cost of the box alone, if you have to pay extra for the software
too, it's an awful expensive solution.

                                          bill gunshannon
                                       [email protected]

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 18:35:33 EDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   unauthorized hacking
"an unauthorized hacker"


my, what an interesting term. . . . . 

> Can I assume this is atypical of this list?

in general, tcp-ip seems pretty good in the light to heat index.


stev knowles
authorized hacker,
ftp software
[email protected]


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 16:17:10 GMT
From:      [email protected]  (John Cristy)
To:        [email protected]
Subject:   Unisys A-Series to Unix WorkStation Connectivity
  I need either a TCP/IP or BNA network solution that can connect a Unisys 
  A-Series to a Unix workstation (Sun, Dec 3100, etc).  Please Email
  recommendations to [email protected]  Thanks in advance.
--
The UUCP Mailer
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 17:17:18 GMT
From:      [email protected]  (Kraig Meyer)
To:        [email protected]
Subject:   Re: toll restrictors
||Andrew Heybey wrote:
||> ...on a unix system, telnet is a user program that opens a 
||> socket....Does your system not allow unprivilidged users to 
||> open network connections?  Are you relying on nobody knowing 
||> how to write/compile/etc their own program to use the net?  Or 
||> does your system have some other mechanism for controlling 
||> network access?

In article <@ocdis01.af.mil> [email protected] (Robert Johnson) writes:
||...By 'turn off', I mean we change permissions so only a trusted group 
||of individuals can use it - not the user population at large.  We protect 
||telnet, ftp, cu, tip, and the compilers and debuggers this way.  We also 
||have daily reports showing who is using these functions...[this] maintains 
||full accountability of our connectivity with other systems.

Bob, I'm still curious whether the operating system you are using actually 
has a way of preventing a user from opening his or her own network connection.
Under unix and many other OS, opening a network connection does not require
any special privileges.  On such a system, taking away a user's ability to 
run your copy of telnet, ftp, etc. does not take away a user's ability to 
telnet, ftp, etc. by using his or her own program.

*****************************************************************************
Kraig Meyer                                                [email protected]
On parole from the University of Southern California.     All views expressed
are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 18:17:34 GMT
From:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   (none)
In-Reply-To:  jas AT proteon.com   -- Fri, 1 Jun 90 11:56:15 EDT

John has made serveral good points but I was not aware that there was any
single point of contact for internet. I guess I thought anyone with sufficient
funds could connect to the internet. I guess part of the fault lies in the
apparent fact that there is no accountability requirement for internet
connections.

In any case it seems that the problem could be partly solved by the listserv
software itself. Simply reject any messages that do not have verifiable
Received: lines built. That wouldn't stop messages to non-listserv users but
those don't get distributed to hundreds of users. If the netnews folks want
their users to access internet lists then they can build Received: lines. If
they don't care then forget leave it the way it is. This type of problem is
cured in any event.

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

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 18:37:24 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   Are you tired of working on top of TCP/IP ??
Hi...

	Are you tired of working on top of TCP/IP ??  Here is a good news
from our Informix SQL Access Group. My RDA (Remote Database Access, ISO/IEC
DP 9579-1) is now about to work. Currently, it is running on top of SunLink OSI
("pure" OSI stack) and on top of TCP/IP with RFC 1006 both as a loopback mode 
on my SPARCstation 1.

	Initially, I embedded it into ISODE-6.0 (== 50 MB, a public domain 
software which was developed under the contract from the U.S. Defense Advanced 
Research Projects Agency and the U.S. Air Force).

	Right now, my RDA is of a size with about 5 MB. It will be much bigger
than now. Still I need a long way to go for the final product. The source codes
are strictly confidential. We need to have someone starts working on the portion
of mapping SQL to RDA services so that our RDA can interface with ESQL/C.
We also need to have someone who can work RDA with me plus a testing guy as soon
as possible. 

	I hope we can replace our product with this OSI and TCP/IP-based
product in the near future. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 22:55:50 EDT
From:      [email protected] (Ralph E. Droms)
To:        [email protected]
Subject:   CFP SIGCOMM-SIGGRAPH Workshop on Graphics and Networking
			   Call for Participation
	    SIGCOMM-SIGGRAPH Workshop on Graphics and Networking*
			     16-18 January 1991
		  National Center for Atmospheric Research
			      Boulder, Colorado


      The  futures  of  graphics  and  networking  are  closely  linked
      together.  The spread of networked workstations with high-quality
      bit-map displays has  encouraged  the  creation  of  environments
      which  use  networks  to exchange graphics images.  The advent of
      fiber-optic networks, with gigabit data  bandwidths,  capable  of
      carrying  data  fast  enough to support real-time graphics, seems
      likely to encourage further integration of the two fields.

      The goal of this workshop is to bring together key members of the
      graphics and networking communities, including people involved in
      research, development and standards, to discuss  concerns  common
      to the two fields.  Topics of discussion are expected to include:
      What are the critical interactions between work in  graphics  and
      work  in  networking?  How will current and future graphics stan-
      dards affect  current  and  future  networking  protocols?   What
      effect  will  new  developments  in each field have on the other?
      Suggestions of additional topics are welcomed.

      The workshop format will be three days of plenary meetings,  with
      each  day  having  four  sessions.   Each session will start with
      brief presentations (5-10 minutes) by  selected  attendees,  fol-
      lowed  by  discussion.   A meeting report will appear in the SIG-
      GRAPH and SIGCOMM newsletters.

      How To Participate

      To ensure a good interaction between participants,  the  workshop
      is  limited to no more than 75 people.  We will try to give every
      attendee the opportunity to give a very short talk.  If  you  are
      interested  in  attending,  send a two paragraph application that
      describes your background, and the topic or topics you would like
      to discuss, to the program co-chairs by October 22:

      Dr. Ralph Droms          Dr. Robert Haber
      Computer Science Dept.   Dept of Theoretical and Applied Mechanics
      Bucknell University      University of Illinois
      323 Dana Engineering     111J Talbot Lab
      Lewisburg, PA 17837      104 South Wright St
			       Urbana, IL 61801
      +1 (717) 524-1145        +1 (217) 333-3826
      [email protected]       [email protected]

      Conference Fees

      The conference fee will be $80 for SIG/ACM members and  $100  for
      non-members.   We expect a choice of hotels, with prices from $35
      to $60 a night.  The workshop itself will be held at the  facili-
      ties  of  the  National  Center for Atmospheric Research which is
      generously contributing the meeting space.

      Student Attendence

      There are spaces reserved for two graduate students to attend the
      workshop.   These  two  students will be asked to keep notes, and
      provide a workshop report which will be printed in  the  SIGGRAPH
      and  SIGCOMM  newsletters.  In return for this work, the workshop
      will provide up to $500 in travel funding for each student.  Stu-
      dents  interested  in applying for these positions should contact
      the conference co-chairs.

*ACM approval pending

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 20:34:32 GMT
From:      [email protected]  (Richard Joltes)
To:        [email protected]
Subject:   Re: (none)
In article <[email protected]> [email protected] (Frank Solensky) writes:
>Yes, it is atypical.  I've been on the list for about a year and this is the
>first time someone at, shall we say, "this level" (note indiscriminate use
>of "O" and "0") has posted this type of thing.

This article (title "COWABUNGA" and sent by someone called "BIFF") seems to 
have been posted to nearly every major newsgroup simultaneously, or nearly so.
I know it's appeared on:

comp.lang.fortran
comp.dcom.lan
comp.dcom.cisco
comp.os.vms
comp.sys.dec
comp.protocols.tcpip
rec.org.sca
rec.arts.startrek

I'm not sure about any others, but someone else said it'd been posted to one
of the security newsgroups as well.  Someone has tried replying and the mail
hasn't yet bounced, which leads me (at least) to believe that some idiot got
access to a friend's account and decided to play.

If anyone reading this is associated with CMU or PSUVM (both mentioned in the
article) they may want to do some checking.  Others already are...

This public service announcement brought to you by...

Dick Joltes					[email protected]
Mgr. of Hardware & Facilities
Harvard University Science Center
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 22:26:43 GMT
From:      [email protected]edu  (Gene Tsudik)
To:        [email protected]
Subject:   Security services in border GWs (was: Suspicious Secure GW)
The inadequacies of the gateway-based filtering have been discussed in a number
of recent messages. To sum things up, it was pointed out (by Phil Karn) that
"..there is no substitute for each individual taking the responsibility for
his own local domain...".

It is hard to disagree with this point of view. However, the argument was in the
context of end-system protection. It is both inadequate and inappropriate for a
gateway to protect hosts that are subject to the outside exposure. Instead,
these hosts should be able to protect themselves.

However, another important issue is the protection of network resources other
than the end-systems. This includes internal gateways, bridges and links. It is
obviously undesirable to have unauthorized external traffic interfere with
local traffic. This is why internal network resources should be protected
from unauthorized use. Note that simply detecting bad packets at the
end-systems is inadequate since by the time unauthorized traffic reaches
an end-system, it has already consumed internal network resources. So, if
protection of network resources is desired, border GWs need to check incoming
packets for i) authenticity, ii) data integrity, and iii) replay.

Furthermore, when an organization connects to an internet, more often
then not, only a small number of select end-systems are exposed. Should all
other strictly-internal end-systems be expected to implement adequate security
measures? The answer is dependent on one's "religion". If one subscribes to

Phil Karn's point of view, there should be no such things as "unprotected "
end-systems in the first place. Alternatively, if there is a need to preclude
any kind of external access to strictly-internal end-systems, border
gateway-based mechanisms can be employed to restrict incoming traffic to
only exposed end-systems. This can be done with complete transparency to
the internal (unprotected) end-systems.

Note, that an intruder can still use the exposed end-systems as a conduit for
accessing the internal systems. However, using Phil Karn's argument above,
the exposed end-systems should ensure that this doesn't happen.

In summary, end-system controls are inadequate for protecting internal network
resources. To control access to such resources, border gateways need to
implement appropriate security mechanisms.

Gene Tsudik and Deborah Estrin

Computer Networks and Distributed Systems Laboratory
Computer Science Department
University of Southern California
Los Angeles, Ca
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 22:27:27 GMT
From:      [email protected].ohio-state.edu  (Roy Smith)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
[email protected] (John A. Shriver) writes:
> if their umbrella organization (usenet) cannot maintain professional
> standards of behavior, then that is their loss.  By implementing a
> system without accountability, they create that risk.

	And there lies the heart of the problem; there is no umbrella
organization called usenet.  At best, usenet is a loose confederation of
cooperating sites.  At worst, it's a anarchy.  You can't blame it on "them"
because there is no "them" to blame it on.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
[email protected] -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 00:17:53 GMT
From:      [email protected]  (Ittai Hershman)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
> The TCP-IP list has been quite consitently professional in its
> conduct, as have most public Internet mailing lists.  Everything
> unprofessional I have seen recently was "gatewayed" in from netnews.

Nonsense.  Witness the recent debate on the IETF mailing list, which
is not gatewayed to netnews, on the subject of tongue-in-cheek
messages.  The "problem" is very simply the price of success -- things
were a lot more professional back in the old days before we let just
anyone (tongue is definitely in cheek here) on the network.

The real problem is that our e-mail/conferencing user-agent paradigms
no longer fit the reality of the Internet.  On a personal level, I use
e-mail pretty much for one-to-one or one-to-small-ad-hoc-group
communication, and use netnews for all mailing-list/conferencing type
activities.  This was a step in the right direction, but the
user-agents are still far too primitive.  There are some intriguing
ideas being developed in the research community and I look forward to
trying them out as implementations are made available.

-Ittai
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 00:38:04 GMT
From:      [email protected]  (Lance C Norskog)
To:        [email protected]
Subject:   Re: Trying to write a bootp client for Ultrix
You have a logical conundrum here.  You are trying to figure out how
to "turn on" IP, but you are trying to use IP to figure this out.

You have to send and receive your own raw Ethernet packets.  Ultrix
may have some technique for doing this.  System V has it's own scheme
where the Ethernet devices have their own /dev entries (jeeez wotta concept)
which you open and "bind" to a protocol number.

good luck.
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Sat, 02 Jun 90 09:34:58 cst
From:      (strick) <[email protected]>
To:        TCP-IP%[email protected]
Cc:        File <[email protected]>
Subject:   tn3270 terminal server
>Does anybody know if anybody makes a terminal server that speaks
>both normal telnet and tn3270?

I understand that the MPG (WISC ware) is a combination terminal server and
IBM 7171.  You can contact Susan Bramhall at [email protected] for more
information.
strick


-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 03:36:07 GMT
From:      [email protected]  (David Lesher)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
Gee, the funny thing is, few of us on the Usenet side were 
bothered by this lid. Why? A responsible net_citizen cancelled
all the garbage before most people saw it. It's a pity your
maillist software won't handle cancels; then you would not have
been annoyed either. Maybe you should fix it. ;-} 

There are things that annoy me about maillist<-->newsgroup bridging.
The chief one is all the "PLEASE UNSUBSCRIBE ME" psotings that it
brings. Nothing is perfect; most of all Usenet. If you are really that
upset by this very unusual event, may I suggest you snag "filter"
from the elm distribution and set it up to bit_bucket all that "trash"
that comes from the bridge site.

I hope this bridge keeps working. I learn a lot reading this
group.



-- 
A host is a host from coast to [email protected] 
& no one will talk to a host that's close............(305) 255-RTFM
Unless the host (that isn't close)......................pob 570-335
is busy, hung or dead....................................33257-0335
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 05:21:22 GMT
From:      [email protected] (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: trash message from usenet (BIFF)
/ comp.protocols.tcp-ip / [email protected] (John A. Shriver) / Jun  1, 1990 /
> I'd rather the "gateways" be made one
> way (out from Internet only), or even non-existent. [...]
> I realize that this would deny netnews/uucp only sites access to the
> Internet mailing lists,

You should also realize that this would deny people on the Internet mailing
list contributions from Usenet users.

> but if their umbrella organization (usenet)

It's not an organization.  It's a community.

> cannot maintain professional standards of behavior, then that is their
> loss.

Ah, I see.  Not your loss.  All the important people are on the mailing lists.

>  By implementing a system without accountability, they create
> that risk.

True.  Funny thing, though: this is what a lot of VMS/DECNET buffs were
saying about the Internet after the Morris Worm.  Until the DECNET worm a
few months later, that is...

> I (and others) would welcome netnews being made properly accountable
> and secure.

Certainly.

But what's so special about mailing lists?  It IS easy to fake Usenet
messages; but are you saying that it's hard to fake messages sent to a
mailing list?

> not building the Received: lines may make netnews
> more efficient, but this removes all vestiges of accountability.  This
> is a key problem.

One can start a mail message with a fake sequence of "Received:" lines just
as easily as starting a Usenet message with a fake "Path:" line (which is
what the cowabanga bozo did).

Jacob
--
Jacob Gore		[email protected]			boulder!gore!jacob

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 07:08:44 GMT
From:      [email protected]  (Stuart Lynne)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
In article <[email protected]> [email protected] (David Lesher) writes:
}Gee, the funny thing is, few of us on the Usenet side were 
}bothered by this lid. Why? A responsible net_citizen cancelled
}all the garbage before most people saw it. It's a pity your
}maillist software won't handle cancels; then you would not have
}been annoyed either. Maybe you should fix it. ;-} 

The other funny thing is that slightly more than half the traffic originates
on this side of the fence. I just did a simple straw poll, out of 88
articles in /usr/spool/news/comp/protocols/tcp-ip, only 34 had originated
from "The Internet".


-- 
Stuart.[email protected] ubc-cs!van-bc!sl 604-937-7532(voice) 
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Jun 90 13:49:53 EDT
From:      [email protected] (Don Tinker)
To:        [email protected]
Subject:   Tsock available for ftp
Tsock, a socket testing/ network performance testing application, is
available for anonymous ftp from sol.ctr.columbia.edu [128.59.64.40]
as pub/net/tsock.tar.Z.

Beginning as "ttcp", a public domain socket-test program written by
Terry Slattery & Mike Muuss at BRL, it's essentially been completely
rewritten.  Like ttcp, tsock opens a socket (as a transmitter or a
reader) and shoves data into/reads data from it; but it includes the
capabilities to:

	o Spread the data over multiple child processes using the same
socket
	o Write data in user-specified buffer sizes (and read data in
user-specified buffer sizes if the underlying network permits this)
	o Send/receive data simultaneously over the same socket (full duplex)
	o Align the data on various memory boundaries
	o Randomize things like buffer sizes and data
	o Send/receive streams or datagrams

(some of these may be in ttcp also; if so, my aplogies to the authors).

And thanks to seth at columbia for providing the space.


Don Tinker				[email protected]
Senior Field Support Engineer		{core}!ames!ultra!tinker
UltraNetwork Technologies Inc. 		(703) 821-8393
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 11:02:18 GMT
From:      [email protected]  (Michael O'Dell)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
The notion that mail or mailing lists on the Internet are either
"secure" or "accountable" is simply hysterical.
	-Mike
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Sat, 02 Jun 90 21:29:51 -0400
From:      "Martin Lee Schoffstall" <[email protected]>
To:        [email protected] (Phil Karn)
Cc:        [email protected]
Subject:   Re: What is the IAB?
> Indeed it seems
> that several other missteps within the Internet community can be traced to
> this same cause. The use of ASN.1 within SNMP, for example.

Whoa!  ASN.1 was used in SGMP the "experimental" predecessor of SNMP which
NO ONE from the OSI camp had any influence on, PERIOD.  Four people who's
healthy skeptism of ISO technology and politics are world known (you heard
me in Stockholm) needed a format and chose ASN.1 within the SGMP concept
and proved its workability.  The next generation SNMP kept the design
and tradition and use of ASN.1.  ASN.1 was a good choice, NOTHING has
proven this a bad choice.

About every six months there seems to be a little chinese fire drill,
it would appear initated by some of the iconic figures of the Internet,
who talk about performance problems with X,Y,Z areas of SNMP/ASN.1.
All of them have been proven false, and without merit.

SGMP and SNMP went through a very thorough process, of implementation,
review, implementation, review, implementation, review.  Lots and lots
of that good stuff called peer review.  If there was a technical problem
of that size it would have died on the vine.

Marty
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 15:34:58 GMT
From:      [email protected] (strick)
To:        comp.protocols.tcp-ip
Subject:   tn3270 terminal server

>Does anybody know if anybody makes a terminal server that speaks
>both normal telnet and tn3270?

I understand that the MPG (WISC ware) is a combination terminal server and
IBM 7171.  You can contact Susan Bramhall at [email protected] for more
information.
strick

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 21:50:41 GMT
From:      [email protected]  (Phil Karn)
To:        [email protected]
Subject:   Re: What is the IAB?
Yes, I should modify my earlier statement as follows: the IAB *usually*
follows a "fly before buy" policy regarding protocol standardization.  The
fact that political pressure from the OSI camp has occasionally corrupted
the process doesn't make this principle any less important. Indeed it seems
that several other missteps within the Internet community can be traced to
this same cause. The use of ASN.1 within SNMP, for example.

Phil
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 23:18:10 GMT
From:      [email protected]  (Phil Karn)
To:        [email protected]
Subject:   Re: Security services in border GWs (was: Suspicious Secure GW)
In article <[email protected]> [email protected] (Gene Tsudik) writes:
>In summary, end-system controls are inadequate for protecting internal network
>resources. To control access to such resources, border gateways need to
>implement appropriate security mechanisms.

Yes, your conclusion does follow from your premise. The question, though, is
whether this is a real problem. Most private corporate or campus networks
are "stubs" off the main Internet, so what can anyone gain by sending
traffic into such a network without access to a host on that network?
Sabotage of the private network itself is of course a possibility, but this
can be handled by turning on a gateway filter to block the offending
traffic.

I don't oppose filtering gateways per se. I just think they're like police
roadblocks: appropriate during emergencies, but too disruptive for routine
operations.

Phil
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 00:24:36 GMT
From:      [email protected]  (Phil Karn)
To:        [email protected]
Subject:   Re: Dial up access to Internet facilities
In article <[email protected]> [email protected] (RL "Bob" Morgan) writes:
>
>Indeed, SMTP's assumption that everybody's connected all the time
>>doesn't work well with occasionally-connected hosts.  [...]

I'm also very interested in making the Internet protocols work well over
non-full-time paths. 

Here's an idea that I put into my KA9Q TCP/IP package a while ago.  It has a
UDP-based server that handles "kick" requests. These force retransmissions
on any TCP connections to the specified IP address (which defaults to the
sender of the kick message) and they also cause the remote SMTP daemon to
start sending any pending traffic to the destination.

This has turned out to be a useful feature when dealing with dialup links or
the long network outages that are characteristic of some experimental
amateur packet radio links. When the path is up, the person expecting mail
sends a kick request to the site(s) from which he expects his traffic, e.g.,
a mail exchanger. If there's any traffic waiting, it immediately starts to
flow. Also, because my TCP connections never time out (they just back way
off) the kick command lets you pick up a partial transfer right where you
left off when the path broke without having to restart it from the
beginning.

Perhaps it's time for an "intermittent connectivity" working group in the
IETF?

Phil
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 02:00:01 GMT
From:      u[email protected]ucsd.edu  (Henry Spencer)
To:        [email protected]
Subject:   Re: Dial up access to Internet facilities
In article <[email protected]> [email protected] (Barry Margolin) writes:
>>Indeed, SMTP's assumption that everybody's connected all the time
>>doesn't work well with occasionally-connected hosts.  It would seem
>>that the time is ripe for some sort of extension to SMTP...
>
>No extension is needed: see the TURN command.  However, most SMTP
>implementation don't enable this command for security reasons...

TURN is the wrong tool for the job.  What is needed is the equivalent of
UUCP's callback facility:  A connects to B, says "call me", and hangs up.
B then makes the call -- which eliminates the authentication issue -- and
transfers the traffic.

People interested in infrequently-connected hosts would do well to study
how UUCP software and administrators deal with the problems.  There is
a large body of relevant experience there.

>However, I'm not sure why you need any of this.  What's wrong with the
>MX'ing host periodically trying to connect to the occasionally-connected
>hosts? [which is the way it already works] ...

It has the standard problem of any polling scheme:  frequent attempts eat
resources, infrequent attempts can miss "hitting the window" for a site
which is only connected occasionally.  As with most polling, the real
answer is to have the other end *tell* you "now would be a good time".

SMTP's approach assumes hosts that are on the network more or less
continuously, with partitioning and/or downtime a relatively rare and
transient phenomenon that can be dealt with in simplistic ways.  When
the connection, as opposed to the absence thereof, is rare and transient,
more sophisticated tactics are needed.
-- 
As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry [email protected]
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:24:40 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccn[email protected]ucbvax.Berkeley.EDU  (Edward Vielmetti)
To:        [email protected]
Subject:   anonymous ftp, and the dangers thereof
from ftpd(8):
BUGS
     The anonymous account is inherently dangerous and should  be
     avoided when possible.

Despite this dire warning, there are over 500 systems on the internet
which support anonymous FTP.  There are known bugs in several versions
of ftpd which allow crackers to break in; word about this spread rather
quickly around some parts of the net just before the internet worm hit.
The worm didn't expose these vulnerabilities, so there's good reason
to believe that some people are still at risk.

ftpd identifies itself in the login banner like so:

220 stag.math.lsa.umich.edu FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready.

so that a potential cracker need only retrieve this one piece of
information to see whether a system might be susceptible to attack.
There's no guarantee that the date in this banner is the actual
date that the code was fixed, nor does the version number seem to
mean much; but if the version is well known the means of entry can
be assured.  Any BSD'ish system with a date earlier than the berkeley
fixes posted 10/31/88 and 11/18/88 is an easy target, as are systems
for which vendors have supplied fixes.

I would estimate by a sampling of these banners that one host in 10
that does anonymous FTP is vulnerable.  

Some sites keep anonymous FTP directories to be world-writable,
letting any random internet user drop a file in a directory.  If you
see a file named GETMONEY.txt, makemoney.doc, or sex-bbs.doc (or
variations on same) in your FTP directory, this is why.  It is not
good practice to allow random anonymous users to scribble into
directories; several sensible systems have "upload" or "tmp"
directories for submissions, from which an archive manager will
move files into their real homes.  The problem of allowing remote
users to update archives which belong to them should be addressed
with ordinary passworded accounts.

Despite the widespread use of anonymous FTP, the internet RFC's
provide no guidelines to its use or configuration.  The conventions
that define anonymous FTP, its risks, and suggestions on how
to set up a good FTP site should be collected in the form of
an RFC on anonymous ftp.

--Ed

Edward Vielmetti, U of Michigan math dept.
[email protected]
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:01 GMT
From:      [email protected]  (David C. Kovar)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Edward Vielmetti) writes:
>ftpd identifies itself in the login banner like so:
>
>220 xxxxxxxxxxxxxxxxxxxxxxx FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready.
>

  I am not up on which versions of FTP are currently vulnerable but it
strikes me as quite irresponsible to use actual host names in an example.
If nothing else, you're going to get some people FTPing to it just to
see what the scoop is. (I just did to see if you really were using an
actual example.)

  I'm all for securing systems, but you've got to be somewhat intelligent
about doing it. If posts show up in this newsgroup that cause certain
systems to be broken into (ie, by attracting attention to them) then
the newsgroup will go away. Worse still, there is a small chance,
very small given current laws, that you will be held responsible for
any break in caused by your post.
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:23 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu!rpi!zaphod.mps[email protected]ucbvax.Berkeley.EDU  (Eric Wines)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (David C. Kovar) writes:
>In article <[email protected]> [email protected] (Edward Vielmetti) writes:
>>ftpd identifies itself in the login banner like so:
>>
>>220 xxxxxxxxxxxxxxxxxxxxxxx FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready.
>>
>
>  I am not up on which versions of FTP are currently vulnerable but it
>strikes me as quite irresponsible to use actual host names in an example.
>If nothing else, you're going to get some people FTPing to it just to
>see what the scoop is. (I just did to see if you really were using an
>actual example.)
>

I think you are quite wrong.  To be on the internet these days your 
system had better be secure.  Your login accounts had better have good
passwords, your ftp had better be secure, etc.  It would extremely trivial
to query every entry in /etc/hosts for ftp version information.
If it is really a hole don't you think there are hacker's that have
exploited it?
  Would I be wrong to tell a co-worker that some idiot sysadmin at bozo.com
has root wide open without a password (just an example).  My company is not on
the internet.  We may be in the near future.  If this is to happen things
will have to be *extremely* secure on the machine that connects.
I have co-workers who don't really know what the internet is expressing
concern about security in the face of the the possibility of connecting to
it (from what they here on the news).

I think being on the internet is like having a home phone.  Anyone can call
you at anytime, even at 4AM.  You can unplug your phone but that's not really
a solution.  You can get an answering service for a phone to keep people from
bugging you, but for the internet, your system should be secure or you'd
better not care.
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:29 GMT
From:      [email protected]  (Bill Wisner)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
[email protected] (David C. Kovar) writes:

>								     it
>strikes me as quite irresponsible to use actual host names in an example.

He goes on to warn:

>			     Worse still, there is a small chance,
>very small given current laws, that you will be held responsible for
>any break in caused by your post.

Chill out, Dave. Ed used his *own machine* as an example. Really.

Bill Wisner <[email protected]> Gryphon Gang Fairbanks AK 99775
"Wisner, you're scum." -- Matt Crawford <[email protected]>
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:37 GMT
From:      [email protected]  (Mark Crispin)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Edward Vielmetti) writes:
>Despite the widespread use of anonymous FTP, the internet RFC's
>provide no guidelines to its use or configuration.  The conventions
>that define anonymous FTP, its risks, and suggestions on how
>to set up a good FTP site should be collected in the form of
>an RFC on anonymous ftp.

Just as a matter of history, on Tenex and TOPS-20, userid ANONYMOUS
could only write to the PS:<ANONYMOUS> directory (its home directory).
ANONYMOUS could only read files that were on PS:<ANONYMOUS>, group-
accessible to ANONYMOUS (generally never done), or world-readable.

Furthermore, passwords were never stored in any file readable by any
user, even in encrypted form.  The only way to read a password in any
form (including encrypted) was to do a privileged system call.  Anyone
who could do this system call had already broken security (had the
equivalent of root).

The operations which required passwords were system calls which took
the user's attempted password in plaintext.  The encryption algorithm
was in the operating system and there was no specific function to
return the encrypted form of a password (although with enough effort
someone could find out what the encryption algorithm was).  Failed
password attempts were counted, and an excessive failure rate was
cause to bump the user off the system.  Many systems considered *all*
password attempts to be failures at some point before the bump-off
point, so even a valid password would fail.

It worked pretty well.  Most Tenex/TOPS-20 sites had warm fuzzy
feelings about allowing ANONYMOUS and never had any security problems
because of it.  There are lessons to be learned, starting with the
abolishment of /etc/passwd and user access to the encryption
algorithm.
 _____   | ____ ___|___   /__   Mark Crispin           Atheist & Proud
 _|_|_  -|- ||   __|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_|  |\-++-  |===|  /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--  /| ||||  |___|    /\    USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /  \   +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__|  /   \  /    \  [email protected] "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:10:10 GMT
From:      [email protected]  (Jim Hutchison)
To:        [email protected]
Subject:   Passwords in the kernel (was Re: anonymous ftp, and ...)
In article <[email protected]>
	[email protected] (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
>file, once known, can be gotten at.  We are talking about hiding the
>password where only the kernel can get at them.  Granted, a program
>that does absolute disk reads can get at the passwords; but such a
>program (1) can't be run under FTP (2) can only be run by a privileged
>user (and hence the system is already violated).

An interesting idea, you want the kernel to maintain a password database
on a secondary storage device.  This database is not a user accessible
file system.  Nor is it mountable in a normal way, because if it were
it would be able to be left that way by the same careless sysadmin who
bungled the permission bits and ftp setup.

Among other things, who backs it up?  If root must back it up, then you've got
to set up the backup utilities to be run safely by operators...  If "operator"
is going to back it up, it has to be readable by the op.  This being the sort
of problem which seems to prompt people to slam in suid/sgid bits or chmod a+r
things.  Not my solution, but apparently a common one.

Sounds like a mini-nightmare to maintain, based on backing it up (securely!)
and restoring it in the event of a tragedy (one could no longer type it in
using /bin/cat and being able to remember root::0:0:&:/:/bin/sh).  At first
thought I'd think you could use /bin/cat to the raw device, but then you'd have
to remember the major/minor number of it for mknod, and it gets worse from
there.  This is demanding a lot of smart thinking from the sysadmin who is
having so much trouble securing the system.

>We are talking about setreuid() not requiring any privileges, but
>taking a password as an argument.  We are talking about no "setuid"
>programs; in its place are new unprivileged system calls which make
>the necessary checks.

So, the hacker now has to probe individual passwords instead of attacking
the database.  Not much of a win judging by the effectiveness of the
various worms and security studies involving password guessing.

>In other words, we're talking about making it harder for the system to
>be compromised simply by poor file protections!

Please revise, it still looks like "poor filesystem protections",
ftp> set binary
ftp> cd /dev
ftp> get r0xd0b
...

>Unix purists argue that this "adds a lot of junk to the kernel" and
>interferes with the beauty and elegance of Unix.  I hate to break it
>to them, but the Unix kernel hasn't been "small and beautiful" since
>PDP-11 days.

In view of the small gain involved, the massive cost in development,
standardization, and maintenance.  I'd say you hit the nail on the head
when you labeled this "junk".  It is a very interesting idea though.

Perhaps it would work better if the secondary storage device was something
more oriented to security, such as one of those password scratch-pads
I've heard the kerberos folks use on occasion.  Then it'd be an add-on
password library and a device driver.  You might be able to sell a few
million to the government and research facilities.  You could probably
interest Logicon in it, or some other company working on a secure Unix.

--
-
Jim Hutchison   	{dcdwest,ucbvax}!ucsd!fps!hutch
Disclaimer:  I am not an official spokesman for FPS computing
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:15:37 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu!rpi!zapho[email protected]ucbvax.Berkeley.EDU  (Jon Zeeff)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
All this emphasis on turning off tftp and waiting for shadow password 
files may be clouding the simpler and more effective solution.  Force 
users to pick good passwords!  Something with some non-alpha 
characters and mixed case (not the first letter capital).  

Neither turning off tfpd or even shadow passwords will protect you from 
local users or people who used to have root.
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:28:48 GMT
From:      [email protected]  (Warner Losh)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]>
[email protected] (Mark Crispin) writes:
>... There are lessons to be learned, starting with the
>abolishment of /etc/passwd and user access to the encryption
>algorithm.

Sorry.  There are too may passwd files out there to do this.  Shadow
files might help, but then again they might not.  The algorithm for
password encryption is well known and available via anonymous ftp from
many site.  Even if it wasn't, you'd have to put something like this
into the kernel, and we all know that /vmunix is world readable.  That
and a good disassembler would totally defeat whatever you just
gained....

What is needed is a good guide to how to setup anonymous FTP correctly
so that nobody can steal any real files.

Also, while we're on the subject:  Remember what tftp gives the known
universe.  Access to all world readable files.  Turn it off or restrict
it at your site if you are connected to anything resembling the
ineternet.

In article <[email protected]> [email protected] (Henry
Spencer) writes:
>Ah yes, good old security-through-obscurity.  Where have we heard that
>before?

And it doesn't work.  Never has, never will.  The only people that you
will catch by this are the people too lazy to be inventive.  And those
are the people least likely to crack your system anyway.

>If OSI is the answer, what on
>Earth could be the question??

You really don't want to know .... :-)

-- 
Warner Losh					[email protected]
Excuse me sir, this is a spot check.  Can we see your clue please?
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:28:51 GMT
From:      [email protected]  (Wm E. Davidsen Jr)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Henry Spencer) writes:
| In article <[email protected]> [email protected] (Mark Crispin) writes:
| >... There are lessons to be learned, starting with the
| >abolishment of /etc/passwd and user access to the encryption
| >algorithm.
| 
| Ah yes, good old security-through-obscurity.  Where have we heard that
| before?

  I don't know that I have any objections to shadow password. WHy give
the show away? It's like having L.sys or Systems world readable. I
accept that I can't keep the encryption a secret, so why give the
encrypted passwords away. I don't see what this has to do with
security-through-obscurity here.
-- 
bill davidsen - [email protected] (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:28:53 GMT
From:      [email protected]  (Wm E. Davidsen Jr)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Mark Crispin) writes:
|                                    We are talking about no "setuid"
| programs; in its place are new unprivileged system calls which make
| the necessary checks.

  That's nice in the far future, but I'll take what I have and
understand, carefully used. I'm perfectly content to have user programs
use setuid (not to root, thanks) to control access to things like
databases and other user owned resources. I think you could get a few
good theses from thrying to design something better than having the
owner of the resource provide a setuid program to provide access.

  The problem has been that vendors have been to cheap, lazy, or
incompetent to provide services by means other than using setuid root
for things. I regard about 30% of what most vendors do as being the
result of lazyness (not that this implies a security hole in that many
cases, but a lack of elegance).
-- 
bill davidsen - [email protected] (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 09:23:39 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccn[email protected]ucbvax.Berkeley.EDU  (Edward Vielmetti)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> I wrote:

   from ftpd(8):
   BUGS
	The anonymous account is inherently dangerous and should  be
	avoided when possible.

   I would estimate by a sampling of these banners that one host in 10
   that does anonymous FTP is vulnerable.  

You log on to an anonymous FTP site and notice that their FTP appears
vulnerable.  What do you do?

1.  nothing.
2.  break in and do something nasty.
3.  contact the system manager and let them know what's wrong.
4.  break in and leave a note to the system manager to let them
    know what's wrong.
5.  break in, leave a note to the system manager to let them know
    what's wrong, and install a fix.
6.  notify CERT and ask for further guidance.

Option 1 is easy, option 2 also.  Option 3 requires tracking down a
person in charge, as worst you send mail to postmaster.  I won't
recommend options 4 or 5, though I suspect that exercising them
a couple of times would trigger option 6.

Suggestions on the wording of the message to the system manager
welcomed.

--Ed

Edward Vielmetti, U of Michigan math dept.
[email protected]
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Jun 90 17:23:01 -0400
From:      [email protected] (Barry Shein)
To:        [email protected]
Cc:        [email protected]
Subject:   trash message from usenet (BIFF)
>The notion that mail or mailing lists on the Internet are either
>"secure" or "accountable" is simply hysterical.
>	-Mike

I agree, the loudest arguments here appear to be non-sequitars and
"truisms" searching desparately for some pre-determined conclusion.

What I suspect is really at work here is an underlying argument that
"dial-up UUCP is cheap, therefore it must be (security-wise)
inferior".

In fact, those dial-ups require valid login/password pairs before any
delivery is made in virtually every case. The problem actually stems
from abuse of internet software, SMTP and other protocols are
completely vulnerable in much the same way.

But so what?

So is your telephone, what stops me from rigging a box to dial
hundreds of homes in the area at 3AM and play a tape of obscenities?
Say from a pay phone or direct tap (which is analogous to this forgery
stuff), etc. Hell, people do similar things legally around here (those
auto-dialers that tell me to dial this 900 number right now to win my
"free prize"), tho not at 3AM (lord help me if I work nights,
however.)

In the end what we really have to deal with is what standards we are
willing to be measured by.

If we put forth the image that the only reasonable network is one
where it's impossible to post an obnoxious message, ever, and then
communicate that to the public as a minimum standard of viability,
then the technology is doomed, because we will never be able to
deliver that.

This is very critical, and I think many of these protests are
demanding undesirable expectations as if they were tacit and agreed to
by everyone.

They're not, and I still consider my house locked up when I have only
glass in my windows. And I'm willing to put up with the occasional
obnoxious phone call if it keeps phone service easy to use and
inexpensive, or at least deal with it on a per incident basis, etc.

Somewhere in here is a classic exercise in the trade-offs of freedom
vs. security.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | [email protected]
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 15:21:18 GMT
From:      [email protected]  (Peter S. Shenkin)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Jon Zeeff) writes:
>All this emphasis on turning off tftp and waiting for shadow password 
>files may be clouding the simpler and more effective solution.  Force 
>users to pick good passwords!  Something with some non-alpha 
>characters and mixed case (not the first letter capital).  

This suggestion has been mentioned many times on the net, but it also has
a problem.  If passwords are non-mnemonic, unpronounceable and non-suggestive 
(as all "good" passwords are), then they are easy for users to forget;  not 
daily users, but occasional users, such as, say, a biology graduate student 
who logs on once a month to do a DNA sequence search.  Such users often
constitute the vast majority of users on departmental systems.  These users 
then *WRITE DOWN* their passwords, compromising security differently, but 
perhaps as severely, as is now the case.

For a while I had an account on a VMS system which, in the interest of
security, expired my password periodically, and required me to change it.
I mostly used a UNIX system, but had to log into the MicroVAX occasionally
to access a connected array processor;  I was an occasional user.  Keeping
track of my password became such a pain that for a while I wrote it down
and kept it in an unobrusive place, though I didn't like doing that.  
Evenually I discovered that I could change it, then change it right back
to the usual, and the machine wouldn't complain.  I felt a bit guilty
putting something over on the poor machine, but I feel I saved it from itself.
Its security measures were actually compromising security.

Not that I have answers....

	-P.
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb**************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY  10027
(212)854-1418  [email protected](Internet)  [email protected](Bitnet)
***"In scenic New York... where the third world is only a subway ride away."***
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 17:56:14 GMT
From:      [email protected]  (Ken Yap)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]>:
|In article <[email protected]> [email protected] (Jon Zeeff) writes:
|>All this emphasis on turning off tftp and waiting for shadow password 
|>files may be clouding the simpler and more effective solution.  Force 
|>users to pick good passwords!  Something with some non-alpha 
|>characters and mixed case (not the first letter capital).  
|
|This suggestion has been mentioned many times on the net, but it also has
|a problem.  If passwords are non-mnemonic, unpronounceable and non-suggestive 
|(as all "good" passwords are), then they are easy for users to forget;  not 

I once read a good suggestion for choosing a mnemonic, yet hard to
guess password: take a catchy phrase and turn it into an acronym,
capitalizing and inserting punctuation as necessary. For example "Hey
man, don't have a cow" becomes Hm,dhac. I can't take credit (or blame
:-)) for this, I wish I remember the poster who suggested this. If you
are out there, take a bow.

Don't blame me if everybody chooses a Simpsons phrase... :-)
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 20:16:13 GMT
From:      [email protected]  (Will E Estes)
To:        [email protected]
Subject:   TCP/IP Between PCs and Mainframes...What Physical Layers?
Using IBM's mainframe TCP-IP implementations and OS/2 Extended Edition's
TCP/IP, what physical layers can be used?  I assume Ethernet at minimum,
but what about token ring, and what about SDLC since that is how the
vast majority of PCs are linked to mainframes?  Also, what about the case
where a PC goes through a gateway that emulates a 3174 and is connected
by modem to a 3725?

Thanks,
Will Estes        (sun!portal!cup.portal.com!Will)
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 22:32:13 GMT
From:      [email protected]  (John Chambers)
To:        [email protected]
Subject:   Re: Dial up access to Internet facilities
> CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
> a script every night which brings up the dial-up line, and then opens
> a connection to a port on relay.cs.net and tells it to start delivering
> mail to the site.  The application at that connection starts up the
> appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
> where a channel typically has messages destined for a particular site),
> which delivers the mail to the site.  [Note there's no security problem
> here -- anyone can start up the channel, but the channel will only deliver
> to the proper remote system(s)]

How so?  What's to prevent me from running a script of the form:

	for h in foo bar bax glorph `hostname`
	do	hostname $h
		<<Connect to your machine and exchange mail>>
	done

Is there some mechanism for detecting such spoofing?  The only way I can 
think of is by noting info at the link level (Ethernet address, phone number, 
or some such) and comparing, but on most systems, this info isn't available 
to application-level processes.  For instance, how does a process started
from a modem login discover the caller's phone number?  UUCP uses callback 
(if you can figure out how to make it work ;-), but I didn't see any mention 
of that.  What am I missing?

(Yeah, I know I'll also have to run ifconfig for this to work across the
internet.  That's part of the <<code>; give me credit for some smarts! :-)

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 03:37:17 GMT
From:      [email protected]  (Warner Losh)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
In article <[email protected]> [email protected] (Jacob Gore) writes:
>But what's so special about mailing lists?  It IS easy to fake Usenet
>messages; but are you saying that it's hard to fake messages sent to a
>mailing list?

	Jacob makes a good point.  SMTP mail is trivially easy for
anybody with an account on any internet machine to forge.  Details can
be found elsewhere.  The "good" thing about USENET news is that it
puts an explicit path on all messages, so they can be traced fairly
easily.  Given the current state of the art of SMTP daemons, it is
possible to create a message that can't be traced back to the
offending system, much less the user that posted it.

	Fortunately, there is some good working going on to help stop
this.  The new host requirements RFC helps some.  Other efforts are
also in the works.  Some of them are misdirected (like fingering the
"from" line or assuming ports below 1024 are secure), while others are
good (like using heuristics to place a "Warning, this may be bogus" in
the headers).

	Someday we will reach the state where it is not possible to
forge mail, or at the very least we will know where the forgery came
from.  Until that date, you must do what you do with your 50's and
100's today: Double Check them before you accept them.

-- 
Warner Losh		[email protected]
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Mon, 04 Jun 90 13:46:29 EST
From:      Carol Herre <702CH%[email protected]>
To:        [email protected]
Subject:   request list subscription
   I am interested in subscribing to the TCP-IP list.  Could you please
send me the necessary subscription procedures.  Thank you

Carol Herre
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jun 90 12:49:31 EDT
From:      [email protected] (John A. Shriver)
To:        [email protected]
Cc:        [email protected]
Subject:   netnews gatewaying
I will admit that many peoples' counter arguments to me have been
interesting (many sent just to me), including a cute peice of forged
SMTP mail.  I appreciate the comments, and do admit a anti-netnews
bias.  Apologies to those offended.

However, I was glad to see that some comments came out that might
address the problem.  David noted that there is a cancel function in
netnews, and that it nabbed this message fairly quickly.  Maybe the
netnews/SMTP "gateway" agents could put in a delay, maybe an hour or
two, that would allow the "cancel" to do it's work.  Also, maybe there
should be a crude filter program.

I think that we should focus on how to improve this system, rather
than assert that complaining about problems is unfair or evil.  There
is a problem, let's not stick our heads on the sand.  Research is
under way on secure SMTP mail, maybe research is needed elsewhere.  Be
constructive. 

My concern, which I may not have made clear enough, is that the US
Government is potentially watching us.  If they don't like what is
being done with the money the subsidize the Internet with, they might
cut it off.  We live in a glass house, as Barry noted.  The fellow
with the *big* rock is in Washington, D.C., not some hacker.

By the way, my other point about the netnews gateway just came home to
roost.  There is a mail loop on this list, with a delay of over 6
weeks, that just kicked in.  Groan, will that be hard to find.
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 10:24:16 GMT
From:      [email protected]  (Robert Smart)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
Somebody should get the political scientists on to the network news and
the Internet. They are very interesting and succesful examples of a form
of political organization whose name is quite discredited in the world
today, namely anarchy.

If you are interested in the concept of anarchy in a wider context you
should read "The Dispossessed" by Ursula Le Guin. It is a convincing
description of what an anarchy would be like. Not a picnic, that's for
sure. You will have no trouble recognizing the equivalents of people from
our network world, from the idealists who work hard with little thanks
for the common good to the idiots who take advantage of the anarchy's
freedom and don't contribute.

It is easy to see the glaring weaknesses of an anarchic arrangement. Little
incidents show this. But let's not give it away when nothing serious has
happened. The successes far outweigh the problems, and it isn't at all
clear that a more structured or controlled environment would be so
successful.

Bob Smart <[email protected]>
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Mon,  4 Jun 90 19:32:58 -0400 (EDT)
From:      Aaron Wohl <[email protected]>
To:        [email protected], [email protected] (L. Stuart Vance)
Subject:   Re: Interesting uses of networking
I made up a SNMP module for the excel spread sheet.  You can make
up worksheets with data that lives in router or systems (we have a
unix snmp deamon that read /dev/kmem) anywhere on the net.

Glen Marcy ([email protected]) hacked a finger server on a tops20 to
connect to an rs232 line to the airconditioning computer on the roof.
One could finger [email protected]

Someone is cs (try laurence [email protected]) wired up the coke machine.
You could finger [email protected] and see how cold the coke was.
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 13:06:18 GMT
From:      [email protected]  (John F. Haugh II)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Jon Zeeff) writes:
>All this emphasis on turning off tftp and waiting for shadow password 
>files may be clouding the simpler and more effective solution.  Force 
>users to pick good passwords!  Something with some non-alpha 
>characters and mixed case (not the first letter capital).  

Using "good" passwords is meaningless without some control over the
encrypted passwords, because as sure as the sun rises in the east,
people write down "good" passwords.

On the other hand, permitting crappy passwords and protecting the
access to the encrypted crappy password can be secure if the number
of possible trials per unit time is sufficiently small.  A common
feature of many [ including mine ] enhanced login schemes is a limit
to the number of consecutive failures, which limits the number of
failing login attempts on a port to a very small number per unit
time, while not increasing [ by way of using excessively complex
computation scams ] the time to login successfully.  Another feature
is to limit the number of failed attempts on an account before the
account is turned off.

Given this setup using the shadow login code I posted last year,

% faillog -u root -p -u jfh -p
Username        Failures    Maximum     Latest
root                   0          0     Sat May 26 13:49:38 1990 on tty1A
jfh                    1       1000     Mon Jun  4 07:57:21 1990 on tty01

my account will be expired after 1,000 failures.  After 1,000 failed
trials the bad guy will no longer be able to know whether the password
is good or bad.  If I were extremely paranoid I could lower this value
to 10 or so and use trivial english words such as "Cat" or "Dog" without
too much concern.

On my system the maximum failed login rate is on the order of 6 per
minute through the modems.  This is a factor 10,000 slower than
estimates of PCs, which many have stated at being near 1,000 per second.
However, since I control the access to my encrypted passwords, the
problem is serialized at my machine, while someone is perfectly free
to employ two or more other machines to parallelize the problem in an
unprotected environment.

Moral of the story, pester your vendor for shadow password support ...
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: [email protected]

                                            Proud Pilot of RS/6000 Serial #1472
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 16:02:33 GMT
From:      [email protected]edu  (Andrew D Kailhofer)
To:        [email protected]
Subject:   Re: NFS for NCR TOWER
I don't know how much help this will be, but my spies tell me that the
software is not yet general deployment, although there are some CVT
sites, one of which I'm trying to be.

Also, I guess that the software is done out of SE-Copenhagen.

Hope this helps.

Andy

[email protected]
414/678-7793
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 16:04:18 GMT
From:      [email protected]  (Kent England)
To:        [email protected]
Subject:   Re: Security services in border GWs
In article <[email protected]>, [email protected] (Gene Tsudik) writes:
> 
> The inadequacies of the gateway-based filtering have been discussed in
a number
> of recent messages. ...
> 
> Phil Karn's point of view, there should be no such things as "unprotected "
> end-systems in the first place. Alternatively, if there is a need to preclude
> any kind of external access to strictly-internal end-systems, border
> gateway-based mechanisms can be employed to restrict incoming traffic to
> only exposed end-systems. This can be done with complete transparency to
> the internal (unprotected) end-systems.
> 

	What is the essential difference between "routing" (including policy-
based routing) and "access control lists"?  Might the boundary be slightly
fuzzy?  It seems so to me, at least as far as ip-address is concerned.

	For example, if there is a stub domain connected to some transit
routing domain, and the stub advertises routes for nets A and B to the 
transit net (and the transit accepts), should the transit network filter
source addresses to exclude all sources except nets A and B?  Source
address filtering is currently considered to be part of "access control"
and not of "routing" (at least it seems so to me from current implementations
and Requirements RFCs).

	If the transit domain does not include source addresses in
the routing decision, then the transit domain's routing policy can be
overridden by the stub domain, through back-doors and side-doors.  This
is, of course, a current problem in the Internet.

	If one were to say that source address filtering at borders
should be done, then I think we may have redefined a part of
"access control lists" into "routing".  

	Perhaps today's access control list feature is tomorrow's
Router Requirement?   (And so Gene and Phil are both right.)

	--Kent England
	  Boston University
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 16:15:45 GMT
From:      [email protected]  (Dave MacDonald)
To:        [email protected]
Subject:   Re: tcp/ip services <--> decnet connectivity, help wanted
Integrated Information Systems (IIS) which I believe is owned by CDC has
just ported a DECNET product for the HP9000 family.  I have seen it
working on both the 300 and 800 series, and it appears to be very
reasonably priced.

The only number I have for them is for the manager of Business Development
for that product.  He is Randall K. Barker at (513) 427-6379.


Dave MacDonald
Bellevue, WA CEC
[email protected]
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 17:56:33 GMT
From:      [email protected]  (Sharon Fisher)
To:        [email protected]
Subject:   Looking for Unix TCP/IP users
I'm doing a story for Unix World about how users are using communications
standards to help them communicate with other systems.  I'm looking for
users of TCP/IP software other than that by FTP (because I already have
users from them) who are using it to communicate between Unix systems and
other systems.

If you're willing to be interviewed for the article, please email me or
phone me at (415) 664-8845.  Thanks!
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 18:46:29 GMT
From:      [email protected] (Carol Herre)
To:        comp.protocols.tcp-ip
Subject:   request list subscription

   I am interested in subscribing to the TCP-IP list.  Could you please
send me the necessary subscription procedures.  Thank you

Carol Herre

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:14:26 GMT
From:      [email protected]  (Gurvinder Singh Ahluwalia)
To:        [email protected]
Subject:   Access Control Lists (ACLs) on cisco
At what stage is ACL verification done for a session?
[Of course, it is done when a session is established]. 
I wouldn't like to think that every packet has to be 
ACL-verified. Does that sound right? If so, how are
packets decided "go/no-go" across cisco ONCE a session
has been established? How does the cisco relate to 
the concept of a session (for subsequent packets) AFTER 
a session has been authenticated at ACLs? Doing a per
packet ACL-verification sounds like tremendous overhead.

Secondly, what kind of search algorithm is implemented on
ciscos for an optimum and effective ACL search?

Gurvinder Ahluwalia
Phone		: 512/891-3310
Internet	: [email protected]		(PREFERRED)
UUCP		: [email protected]
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:17:26 GMT
From:      [email protected]  (Deepak Munjal)
To:        [email protected]
Subject:   TCP-IP Print Spooler
Does anyone know of a box that will take TCP/IP based Unix spooled 
printer output and convert it something an RS-232 printer can understand?

This is basically a network printer, but all the products I've seen in 
this area are on the Novell architecture.

Any info would be appreciated.

Deepak
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:31:20 GMT
From:      [email protected]  (Bill Stewart 201-949-0705 erebus.att.com!wcs)
To:        [email protected]
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <[email protected]> [email protected] (Noah Friedman) writes:
]In article <[email protected]> [email protected] (Mark Crispin) writes:
]>... There are lessons to be learned, starting with the
]>abolishment of /etc/passwd and user access to the encryption
]>algorithm.
]/etc/passwd is quite useful. A number of my programs use information
]in this database, including the password field, so that other users
]can use their own passwords for various options while running my programs. 
	/etc/passwd has become the traditional location for user-info
	other than passwords, so of course it needs to be kept,
	but I agree with the shadow-password approach that puts 
	(encrypted) passwords in a non-world-readable file.

	Yes, this means that YOUR software can't use the real
	password, but this is good - I'm not going to trust my real
	password to non-system software, because of the increased
	risk of trojan horses and insecurity; terminal-lockers and such
	get their own passwords.

]If DES is breakable, then a new algorithm needs to be implemented. And
]users should be encouraged to choose good passwords, otherwise it
]doesn't matter what encryption mechanism is used.

	The point of the modified-DES used by UNIX is that it isn't
	the same as the real DES, so a real-DES breaker won't work,
	and a fast hardware implementation of real-DES will make it
	hard to search for obvious passwords.  Unfortunately, though,
	people have gotten 10-fold speedups in password encryption
	through software, and hardware is 1-2 orders of magnitude
	faster than the old PDP-11 days (much more, if you have a
	network of machines to bum cycles off of).
	So DES isn't real secure enough either, given readable passwords.

-- 
				Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:47:55 GMT
From:      [email protected].ohio-state.edu  (Jim Lowe)
To:        [email protected]
Subject:   uWave, IP, Video info


	Our local TV people are in the process of setting up a microwave link
here on campus.  They are looking at 23 Ghz systems.  I would like to be able
to add IP traffic to their setup.

	As I understand things, the 23 Ghz systems use a 10 Mhz bandwidth.
DC to 4.5 Mhz is used for the video signal.  They usually put the audio
signal at 6.2 Mhz with a 75 Khz deviation.  They also use 5.8 Mhz (not so
good of an audio channel due to synch buzz) and have second audio channels
at 6.8 and 7.5 Mhz.

	They said we could use one of the second audio channels to run
data on -- using modems at 56kbps.  Personally I would like to use T1 or T2
which should fit in the extra bandwidth.  Unfortunatly the manufacture (Macom)
doesn't offer any T1 capablility -- as far as we know.

	It seems that where we want to have data they want to have video and
visaversa.  It would be real nice if we could find a microwave system that
did video, audio, and at least one T1.

	If you have any experience with running data over microwave links
with video I would like to hear from you.  I would be interested in any
horror stories, actual setups that you are using, manufactures of equipment,
etc...

	Thanks,
		-Jim
		[email protected]

--
	- Jim
Internet: [email protected]				Uucp:	   uwm!james
Bitnet:	  james%[email protected]		Telephone: +1 (414) 229-6431
USmail:   Computing Services Division, P.O. Box 413, Milwaukee, WI  53201
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 00:19:29 GMT
From:      [email protected]  (Lance C Norskog)
To:        [email protected]
Subject:   AT&T's RFS needs a TCP port number
Dear Friends,

AT&T has their own file sharing protocol, called Remote File Sharing or RFS.
It is included (along with NFS) in UNIX V.4.

Since AT&T doesn't seem on the ball about registering an official TCP/IP
port number for RFS, how can we get this going?  We just went through a lot
of pain getting a customer's site set up with RFS over our TCP talking to
RFS over another TCP.  This protocol has been out for three years, and has
built a major installation base.  Not having an official TCP/IP port number 
for it is an oversight that must be corrected.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909 
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 00:27:39 GMT
From:      [email protected]  (Richard Foulk)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
>>Ah yes, good old security-through-obscurity.  Where have we heard that
>>before?
>
>And it doesn't work.  Never has, never will.  The only people that you
>will catch by this are the people too lazy to be inventive.  And those
>are the people least likely to crack your system anyway.

But, there are probably alot more of the "too lazy to be inventive"
types around.

"Security-thourgh-obscurity" certainly isn't great.  But I haven't seen
or heard of any evidence that it's totally useless.

Multiple layers of security would seem to be better than one "perfect"
barrier.

-- 
Richard Foulk		[email protected]
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 00:42:09 GMT
From:      [email protected]ucsd.edu  (Steve Wallace)
To:        [email protected]
Subject:   Re: Access Control Lists (ACLs) on cisco
In <[email protected]> [email protected] (Gurvinder Singh Ahluwalia) writes:


>At what stage is ACL verification done for a session?
>[Of course, it is done when a session is established]. 

IMHO, the cisco should have no notion of a session.  When it's
talking IP, everything is connectionless.  The cisco has to
examine every packet to decide where to route it.  Doesn't seem
like too much more overhead to check an ACL at the same time.
One would assume that they have some-sort-of hash table.

Of course, in the European OSI world things are different.


Steven Wallace
Indiana University
[email protected]
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 09:05:26 PDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   re:  AT&T's RFS needs a TCP port number
Hi.

Port Numbers, Protocol Numbers, etc, are issued by the Internet Assigned
Numbers Authority (IANA).  See RFC-1060 for details, or e-mail to [email protected]

--jon.


----- Begin Included Message -----
Date: 5 Jun 90 00:19:29 GMT
From: [email protected]  (Lance C Norskog)
Subject: AT&T's RFS needs a TCP port number
Sender: [email protected]
To: [email protected],jkrey

Dear Friends,

AT&T has their own file sharing protocol, called Remote File Sharing or RFS.
It is included (along with NFS) in UNIX V.4.

Since AT&T doesn't seem on the ball about registering an official TCP/IP
port number for RFS, how can we get this going?  We just went through a lot
of pain getting a customer's site set up with RFS over our TCP talking to
RFS over another TCP.  This protocol has been out for three years, and has
built a major installation base.  Not having an official TCP/IP port number 
for it is an oversight that must be corrected.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909 
----- End Included Message -----

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 06:10:43 EDT
From:      [email protected] (Dennis Perry)
To:        [email protected], [email protected]
Cc:        [email protected], [email protected]
Subject:   Re:  netnews gatewaying
	Date: Mon, 4 Jun 90 12:49:31 EDT
	From: [email protected] (John A. Shriver)
 	
	My concern, which I may not have made clear enough, is that the US
	Government is potentially watching us.  If they don't like what is
	being done with the money the subsidize the Internet with, they might
	cut it off.  We live in a glass house, as Barry noted.  The fellow
	with the *big* rock is in Washington, D.C., not some hacker.
	
I might illustrate the above point with a true example from my experience
while I was at DARPA 'responsible' for the Arpanet.  It seems that a note
was posted to a netnews list.  The note requested that those interested 
in helping a certain central american country to volunteer their services.
Well, the help requested was for the side of the controversy that the U.S.
government was not interested in helping, at the time.  This note was
picked up by a distribution list on the Arpanet and was eventually collected
and read by certain people located in a certain place.  I was shortly
thereafter contacted by the DOD Inspector General's Office in the Pentagon.
There inital concern was to shut down the Arpanet.  After a more logical
discussion, a course of action was identified which amounted to an
educational experience for the person posting the note and the institution
passing the note on to the Arpanet.

The above details may not be totally correct, since this happened about
four years ago now, and I try not to remember the things that are unpleasant
in my life.

dennis

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue 5 Jun 90 10:35:24-PDT
From:      William "Chops" Westfield <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: TCP-IP Print Spooler
Any number of tcp terminal servers can be configured in various ways
to allow rs232 printers to talk to unix spooling systems.  The three
common ways are:

	1)  hack lpd to know about tcp connections.

	2) hack the printcap files so that the appropriate filters
	   do the actual data transmission instead of lpd.  This is
	   probably the easiest.

	3) various utilities will create a /dev/foo type device which opens
	   a tcp connection to an appropriate destination when accessed.


Bill Westfield
cisco Systems.
-------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jun 90 10:02:29 EST
From:      Carol Herre <702CH%[email protected]>
To:        [email protected]
Subject:   Networking MacIntosh Machines
I am looking for information regarding the addition of Macs to an existing
TCP/IP network.  We have a Mac system on the net using NCSA Telnet, but we
would like to have the same features for the mac that are available for the
PC with Sun's PC-NFS.  We want to be able to transparently share files that
may reside on a DEC VAX running VMS, a DEC MicroVAX running Ultrix or a Sun
Workstation.  Your assistance is appreciated.  Thank you.

Carol Herre
University of Scranton
Scranton, PA
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 10:32:31 EDT
From:      [email protected] (bob williams)
To:        [email protected]
Subject:   add to list
     Vivian , pls add me to the list & confirm reciept.

          thank you 
                   Bob Williams
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jun 90 14:50:33 EST
From:      bill gunshannon <702WFG%[email protected]>
To:        [email protected]
Subject:   PC NFS Clients
Are there any Public Domain or freely available NFS Client packages
around??   Source would be nice but I could live without it.  I have
a department that would like to see if NFS is the answer. Being as I
am not exactly sure what is the question, I would like to find a cheap
way to let them try it out.  I already have a PC NFS Server, and need
only Clients to start testing.


bill

                                          bill gunshannon
                                       [email protected]

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jun 90 21:50:17 -0700
From:      Marshall Rose <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
I think you've missed April Fools' Day by about 2 months and 4 days!
But, if you were serious, then you are probably 9 years, 9 months, and
26 days premature in sending your message.

The Internet suite of protocols is only now coming into its own.  This
"old" technology is quite vibrant and has a lot of life flowing into it.
It is also the only thing that works today across multiple vendor lines.
Further, when meaningful comparisons can be made, it also seems to be
best technology around, as evidenced by its wide deployment and ever-maturing
market.

If Korea and Japan really have thrown out TCP/IP (which I don't believe
for a second), then they've made a strategic error.  Certainly in
Europe, the bastion of OSI, they've determined that if you want to
actually do networking, as opposed to talk about networking, then you do
it with TCP/IP.  I know of several places in Europe where the phrase
"IP router" is utterred with reverence and occasionally awe!

Although I'm hopeful that someday OSI might produce competitive
technologies, I'm not going to hold my breath.  It is not enough to do
something different, you must do it better, a lot better.  Although
service for service, the OSI effort is more ambitious than the Internet
approach, the OSI pseudo-products on the market are, by and large, much
less functional and robust than their Internet competitors.  It is not
enough to have a standard for multi-media message handling (X.400), you
must implement it fully and ubiqiutously in order to displace a
omnipresent memo-based system (RFC822).  And yet, when I survey the
X.400 offerings on the market, I still find many lacking features found
in many of today's RFC822 implementations, and at prices that are truly
astounding.  The same is true, sadly, for FTAM, and VT.  (And this
really isn't the fault of the vendors!  OSI technology is extraordinarly
expensive to produce in terms of time and people.)  I have high hopes
for OSI Directory Services (X.500), since there really isn't a
competitor in the Internet suite; but, I fear that political problems
will make a global Directory improbable.

If you are interested in transition technology, there have been papers
and books printed on this subject for nearly a decade (you might start
with Green's paper on "Protocol Conversion" in IEEE Trans. on Comm.,
March, 1986).  There are also some things specific to Internet->OSI
transition, for example one popular book on OSI devotes about 90 pages
to the topic.

/mtr
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 15:16:59 EDT
From:      [email protected]
To:        [email protected]  (Warner Losh)
Cc:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
*>Ah yes, good old security-through-obscurity.  Where have we heard that
*>before?
*
*And it doesn't work.  Never has, never will.  The only people that you
*will catch by this are the people too lazy to be inventive.  And those
*are the people least likely to crack your system anyway.

i know alot of people who have used the ITS systems at MIT. i never recall
them telling me of problems with people "breaking in" and damaging
something. what security ITS had was based on obsurity. i would like to hear
from some of the ITS wizards about how security-through-obscurity wrked for
them. 


*>If OSI is the answer, what on
*>Earth could be the question??
*
it is a very stupid question . . .. .. 
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 15:17:54 EDT
From:      [email protected]
To:        [email protected]
Subject:   IR/microwave links

(*sigh*) the usual sources of arcane knowledge have dried up. can you help
me? 

are you using an IR or Microwave link for bridging between two buildings?
are you happy? owuld you mail me the information you have (including someone
at the comany to call)?


muchly thanx.

stev knowles
[email protected]

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 00:04:36 -0700
From:      [email protected] (Steven M. Schultz)
To:        [email protected], [email protected]
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
>From: [email protected]  (Bill Stewart erebus.att.com!wcs)
>References: <[email protected]>, <[email protected]>
>
>	/etc/passwd has become the traditional location for user-info
>	other than passwords, so of course it needs to be kept,
>	but I agree with the shadow-password approach that puts 
>	(encrypted) passwords in a non-world-readable file.

	just a "thought" - if the (shadow)file is non-world readable and the
	system is administered "correctly" then why bother with
	encryption at all ;-)

	Steven
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 17:42:23 EDT
From:      [email protected] (Arthur Dertke)
To:        [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected].org
Subject:   Sun Survey
I am attempting to put together a listing of any hosts employing DoD
protocols (TCP/IP, SMTP, FTP, TELNET) that cannot interoperate with hosts
employing Sun's implementation (Version 1.2 for FTP/TELNET/SMTP or Version
1.1 for TCP/IP) of DoD protocols.  I require a response by COB 7 Jun 90.
Any information that can be forwarded, no matter how minor, would be
appreciated

		Arthur Dertke




-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 15:02:29 GMT
From:      [email protected] (Carol Herre)
To:        comp.protocols.tcp-ip
Subject:   Networking MacIntosh Machines
I am looking for information regarding the addition of Macs to an existing
TCP/IP network.  We have a Mac system on the net using NCSA Telnet, but we
would like to have the same features for the mac that are available for the
PC with Sun's PC-NFS.  We want to be able to transparently share files that
may reside on a DEC VAX running VMS, a DEC MicroVAX running Ultrix or a Sun
Workstation.  Your assistance is appreciated.  Thank you.

Carol Herre
University of Scranton
Scranton, PA

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 17:03:57 GMT
From:      [email protected]  (Kent England)
To:        [email protected]
Subject:   Re: uWave, IP, Video info
In article <[email protected]>, [email protected] (Jim Lowe) writes:
> 
> 	Our local TV people are in the process of setting up a microwave link
> here on campus.  They are looking at 23 Ghz systems.  I would like to be able
> to add IP traffic to their setup.
> 
> ...
> 	They said we could use one of the second audio channels to run
> data on -- using modems at 56kbps.  Personally I would like to use T1 or T2
> which should fit in the extra bandwidth.  Unfortunatly the manufacture
(Macom)
> doesn't offer any T1 capablility -- as far as we know.
> 
> 	It seems that where we want to have data they want to have video and
> visaversa.  It would be real nice if we could find a microwave system that
> did video, audio, and at least one T1.
> 
	It can be tough sharing bandwidth between two separate organizations.
But it is doable, since we have done it on a campus broadband system.

	Rather than try to shoehorn data into TV bandwidth, what if you got
separate service?  You could share the antenna (using dual feed), but then
you could get your own non-competing bandwidth for data.  The advantage is
that you could buy Ethernet-on-microwave gear and get 10Mbps for less
than the cost of T1.

	That way you wouldn't have to try to run your LAN service on
someone else's mux gear.  Keep it simple.  Since it is a private network,
you have no technical reason to adhere to telco standard interfaces.

	Kent England
	Boston University
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 17:37:50 GMT
From:      [email protected]  (Reiner Petersen)
To:        [email protected]
Subject:   Re: SLIP source wanted for HP9000/340
In article <[email protected]> [email protected] (Marcel Bernards) writes:
[] Hello NetReaders,
[] I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5 / 7.0.
We are interested too.

-- reiner
-- 
Reiner Petersen, TU-Berlin	BITNET: reiner at db0tui62  
				UUCP:	[email protected]
				path:	...!pyramid!tub!coma!reiner (overseas)
					...!unido!coma!reiner	    (Europe)
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 02:13:39 -0400
From:      der Mouse  <[email protected]>
To:        [email protected], [email protected]
Subject:   Re:  Growing sentiment against gateways
> The problem is the absolute complete and total lack of any sort of
> security, trackability, or accountability in the netnews system that
> runs on usenet (uucp) and over nntp.  The problem is that most of the
> Internet mailing lists have been "gatewayed" to netnews mailgroups.

Not really.  I could generate a letter here which appeared to come from
anyone I chose; the same lack of accountability has always existed on
the Internet too.  I think the reason the Internet hasn't suffered as
much is threefold: (a) it's somewhat more difficult to fake stuff on
the Internet, (b) it's less like the "bulletin board" atmosphere that
seems to breed twits like BIFF than usenet is, and (c) it costs more to
connect to the Internet (IMO this is probably the strongest of the
three).

> I'd rather the "gateways" be made one way (out from Internet only),
> or even non-existent.

About all I can say is, start your own mailing list.  If enough people
agree with you, it'll catch on.  (If nobody agrees with you, there's
not much chance of getting your way in any event.)

> (One could argue that those "gateways" violate the access rules for
> the Internet, since they cannot verify that the message came from an
> authorized user of the Internet.)

You mean there *are* access rules for the modern Internet?  This sounds
suspiciously as though you're thinking of the DARPA rules, which (it
seems to me) don't really apply, with the demise of the ARPAnet core.

> I realize that this would deny netnews/uucp only sites access to the
> Internet mailing lists, but if their umbrella organization (usenet)
> cannot maintain professional standards of behavior, then that is
> their loss.  By implementing a system without accountability, they
> create that risk.

There is no umbrella organization to usenet.  (This is at once one of
its great weaknesses and one of its great strengths.)  I wouldn't worry
about denying them access; most to all Internet mailing lists are
perfectly happy to subscribe addresses which happen to be on uucp-only
machines - I read sf-lovers that way myself for a while, back when I
had no other way.

> Another problem due to "gatewaying" has been consistent recurring
> problems with mail loops through netnews.

And I've seen plenty of mail white-holes on the Internet.  Proves
nothing.

> I (and others) would welcome netnews being made properly accountable
> and secure.  However, not building the Received: lines may make
> netnews more efficient, but this removes all vestiges of
> accountability.  This is a key problem.

Again, I can't say much but "if you find the game unacceptable then
don't play".  If you find netnews unacceptable, don't use it.  If you
can't stand the gatewaying of netnews into (say) the tcp-ip list, then
unsubscribe.  "But there's all that useful information!"  Yes.  But it
amounts to saying that there's useful information in a forum you find
intolerable, and all I can say is "too bad"....

					der Mouse

			old: mcgill-vision!mouse
			new: [email protected]
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 19:41:15 GMT
From:      [email protected]  (Jeff Makey)
To:        [email protected]
Subject:   MILNET connectivity woes
It never occurred to me that the demise of the ARPANET (net 10) would
turn the MILNET into an Internet backwater, but that is what seems to
have happened.  After more than 24 hours of getting "destination
unreachable" messages whenever I try to connect to other parts of the
universe I called the MILNET trouble desk, only to learn that our link
to the NSFnet is down.  Somehow, I thought we were better connected
than that.

USENET traffic seems to be flowing well: a testimony to the advantages
of using truly redundant paths.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: [email protected]    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 19:50:33 GMT
From:      [email protected] (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   PC NFS Clients
Are there any Public Domain or freely available NFS Client packages
around??   Source would be nice but I could live without it.  I have
a department that would like to see if NFS is the answer. Being as I
am not exactly sure what is the question, I would like to find a cheap
way to let them try it out.  I already have a PC NFS Server, and need
only Clients to start testing.


bill

                                          bill gunshannon
                                       [email protected]

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 20:02:57 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
Hi...

	I would like to propose to create a new newsgroup "comp.protocols.
migrate.to.iso" in order to discuss about migration from old TCP/IP technology
to new OSI technology. I've been working on TCP/IP almost 10 years now. I am 
so tired of it. Since the U.S. Government is getting so poor, they cannot 
afford to change their environments so quickly. Only thing they can think of
"Security, security !!", I guess. 

	I had a chance to go back to Korea about a year ago. Not many people  
wanted to talk about TCP/IP. They think it is now pretty old technology.
Wealthy countries like Korea, Japan, they quickly threw out the old TCP/IP
technology. I know Korea has sucked all of the highest technologies from all 
over the world. 

	Anyhow, I would like to propose to create such a new newsgroup. Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

-------------------------------------------------------------------------------
Disclaimer: The above opinion was nothing to do with my employer.
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 21:31:52 GMT
From:      [email protected]du  (John F. Haugh II)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Richard Foulk) writes:
>"Security-thourgh-obscurity" certainly isn't great.  But I haven't seen
>or heard of any evidence that it's totally useless.

The most common example of "Security Through Obscurity" is hiding the
password encryption algorithm.  Read "Password Management Guidelines"
from the NCSC [ or Dod ] [ it is one of the green books in the rainbow
series ] for information on why this is a bad idea.  Other "obscurity"
techniques have similiar problems.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: [email protected]

                                            Proud Pilot of RS/6000 Serial #1472
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 22:01:09 GMT
From:      [email protected]  (Marty Hoag)
To:        [email protected]
Subject:   LANWatch User List Formed
   We have set up an e-mail list for users of the FTP Software LANWatch
program.  If there are other users of LANWatch out there who would like
to be added to the list please let me know.

   While LANWatch has its roots in netwatch our idea is to focus the
discussion on this list to the LANWatch product specifically.  Possible
topics for discussion include sharing usage ideas, discussing possible
enhancements we would like to see, etc.

-----------
Marty Hoag
ND Higher Education Computer Network    US Mail: NDSU Computer Center
Phone: (701)-237-8639  Fax: (701)-237-8541       PO Box 5164 / UCCS
Bitnet:   [email protected]    (NOTE 0 = ZERO)    Fargo, ND  58105
Internet: [email protected]
UUCP:    ...!uunet!plains!vm1.nodak.edu!nu021172
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 23:30:04 GMT
From:      [email protected]cis.ohio-state.edu  (Eliot)
To:        [email protected]
Subject:   Re: netnews gatewaying
John Shriver:

> ...maybe research is needed elsewhere.

You might be relieved to know that there are a number of us working on
the problem, most notably Stan Barber and Brian Kantor.
-- 
Eliot Lear
[[email protected]]
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 00:15:37 GMT
From:      [email protected]  (Bill Stewart 201-949-0705 erebus.att.com!wcs)
To:        [email protected]
Subject:   Re: Dial up access to Internet facilities
In article <[email protected]> [email protected] (Henry Spencer) writes:
]The reason why a zoology department (!) was a major networking hub
]at U of T for some years was that everybody else was so obsessed with
]Internet (or better) performance that they wouldn't even look at silly
]ideas like networking via low-speed modems.  

]-- 
]As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
]features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry [email protected]

It's nice to see that Henry does have a balanced view of things,
regardless of what his .signature may imply :-)  (Tanenbaum, aside
from any OSI politics, is the author of Minix, which was designed to
provide features at the cost of some speed on a machine where speed
was in short supply already - a successful and nice project.)

I've always been surprised at how much you could accomplish with UUCP;
my main disagreement with the SMTP approach, other than the
appalling overcomplexity of sendmail, is that it wants to make a
connection NOW, and send traffic the whole way, rather than settling
for store-and-foreward on a message basis.  While uucp was always a
pain to maintain, the major cause of problems seemed to be
inadequate numbers of modem ports.
-- 
				Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 01:07:48 GMT
From:      [email protected]  (David S. Herron)
To:        [email protected]
Subject:   Re: Dial up access to Internet facilities
In article <[email protected]> [email protected] ("Martin Lee Schoffstall") writes:
> 	The plight of many small technical businesses is that we just cannot 
> 	justify spending $30K+...
> 	  Were access fees brought inline with the level of 
> 	service offered
>Somehow dialup Internet access and SMTP don't go hand and hand in my mind,
>my estimate is that your going to have keep a connection open for about 3 hours
>every day to have some probablity of synchronizing with all the SMTP
>agents pushing mail out of their queues for the site.  Realistically you'll
>be running uucp/tcp to a site like UUPSI who is MX'ing for your domain.

Hmm..  interesting discussion.

uucp/tcp isn't a good choice because the transition through rmail
loses information and bursts messages going to multiple recipients.
There's a bunch of CSNET like tricks that can be played to make this 
work out better.  For instance, a "relay" machine could be advertised
as a fairly low cost MX alternative for the true site causing mail to
be dropped at the relay.

Oh, but does sendmail choke a bit when it has lots of undeliverable
mail in its queue?  Sigh, such is life...  :-)


Count me in as a potential customer of low cost IP service.  It'd be
real nice, when travelling, to be able to reach my home site w/o problem.
For day-day work-at-home stuff I think I can manage to arrange something
local without too much expense, especially since my home line isn't charged
as a business line.  "On the road" is another matter entirely..  
-- 
<- David Herron, an MMDF weenie, <[email protected]>
<- Formerly: David Herron -- NonResident E-Mail Hack <[email protected]>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Jun 90 08:31:38 EDT
From:      "John P. McCarthy" <[email protected]>
To:        [email protected]
Subject:   Re: tn3270 terminal server
Pete,

Cisco Systems is in the stages of developing a tn3270 terminal server.
It should be in Beta in a month or so.  The terminal server also
supports SLIP.

 ---------------------------------------------------------------------
| John P. McCarthy              < EOO104 @ URIACC >    U   U RRR  III |
| Data Communications Tech.                            U   U R  R  I  |
| Academic Computer Center                             U   U RRR   I  |
| University of Rhode Island    "That's all Folks!"     UUU  R  R III |
 ---------------------------------------------------------------------
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 05:04:16 GMT
From:      [email protected]  (Karl Auerbach)
To:        [email protected]
Subject:   Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
In article <[email protected]> [email protected] ("Martin Lee Schoffstall") writes:

>About every six months there seems to be a little chinese fire drill,
>it would appear initated by some of the iconic figures of the Internet,
>who talk about performance problems with X,Y,Z areas of SNMP/ASN.1.
>All of them have been proven false, and without merit.

I've often thought Chinese Fire Drills were fun.  Consequently:

I've worked with X.409 and ASN.1 for rather a few years now.  And it
can be a real pig.  In my SNMP code, my profilers indicate that an
overly large portion of the of cycles are spent in the ASN.1
encoder/decoder.  Maybe my code is inefficient -- although I doubt it.
It's just that while ASN.1 is good for representing things like
electronic mail/mixed-media mail and stuff, it is really a bad choice
for fast transactional things.

(Actually my complaint isn't so much against ASN.1 as it is against
the BER [Basic Encoding Rules].  A few months ago there was an article
in the the SIGCOMM Computer Communications Review about an improved,
alternative BER.)

It is my opinion that the TCP/IP community would be wise to avoid
ASN.1 for any but its (original) purpose: electronic mail.

				--karl--
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 13:23:58 -0400
From:      [email protected] (Barry Shein)
To:        [email protected]
Cc:        [email protected], [email protected]
Subject:   anonymous ftp, and the dangers thereof
>i know alot of people who have used the ITS systems at MIT. i never recall
>them telling me of problems with people "breaking in" and damaging
>something. what security ITS had was based on obsurity. i would like to hear
>from some of the ITS wizards about how security-through-obscurity wrked for
>them. 

Far be it for me to represent myself as an ITS "wizard", but I did use
the system way back when (late 70's early 80's.)

I don't think "security-by-obscurity" was really the key to whatever
success they had (maybe a little), I'd say it was more a mixture of:

	a) those were different times, the community was far different.

	b) Detection was always a real possibility on ITS, I remember
	doing something dumb (like accidently looping myself thru a
	two-layered CRTSTY) and almost immediately getting a blast
	of "WHAT THE HELL ARE YOU DOING!?" on my screen.

	c) Coupled with (b) was the fact that so many of us on the
	machines were "tourists", guests, and losing access for being
	a nuisance was a real possibility. These were the days before
	you could say "so what, I'll just go home and play with my PC".
	A lot of us really needed our accounts (I was doing research
	that really benefitted from occasional, intense access to
	Macsyma, for example, and the e-mail and all that of course.)

	d) those were different times, it was a *lot* more likely
	that whoever you were the people you might be screwing knew
	you professionally and all that. Or could get to you thru
	one layer or so in the people network (e.g. if I had fouled
	the system and someone got ticked off I was just over at
	Harvard and how hard would it have been to have a prof at
	MIT call my boss, another prof, and make my life hell?)

Detection coupled with accountability seems to me to be the real
lesson.

Just like (uh-oh, he waxes philosophic) our inner cities have become
anonymous jungles where no one knows anyone very well and cares even
less what they do, so are our networks becoming.

Try living in a small town all your life and then suddenly start
living "well" with no obvious source of income to justify it and see
how long it is before people start taking an interest in finding out
how you do that. Try the same thing in a big city, no one will care
unless the bureaucrats happen to notice it.

Somewhere in there lies the lesson I think everyone is looking for.
When systems become big and anonymous people will abuse "the system",
the people that system represents become abstracted and unimportant.

It's the price of populist visions of success.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | [email protected]
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 14:07:43 PDT
From:      [email protected] (Kwang Sung)
To:        [email protected]


>From: [email protected] (Marshall Rose) wrote:

>I think you've missed April Fools' Day by about 2 months and 4 days!
>But, if you were serious, then you are probably 9 years, 9 months, and
>26 days premature in sending your message.

Yes. I am so serious. We need to create a new newsgroup "comp.protocols.
migrate.to.iso". For instance, recently I've designed and implemented RDA 
(ISO/IEC DP 9579-1) on top of SunLink OSI and TCP/IP with RFC 1006 on my 
SPARCstation 1. Actually, I've embedded it into ISODE 6.0.  However,
a lot of customers wanted to put it on top of lpp (RFC 1085). I have a trouble
with finding those specific bridges between RFC 1085 and "pure" OSI stack.
If we create those new newsgroup, then we can have an info on migration from
"old" TCP/IP technology, SNA, or other protocols to "new" OSI technology.
As far as I know, application gateways, transport gateways, network tunnels,
protocol tunnels, etc are the only primitive methods for the migration. 
Actual environment needs higher technology.

>The Internet suite of protocols is only now coming into its own.  This
>"old" technology is quite vibrant and has a lot of life flowing into it.
>It is also the only thing that works today across multiple vendor lines.
>Further, when meaningful comparisons can be made, it also seems to be
>best technology around, as evidenced by its wide deployment and ever-maturing
>market.

I don't quite agree with it. As I've explained, since the U.S. Government is
getting poorer, they can not afford to replace the "old" technology. Moreover,
they don't want have an error especially under tactical environments. That's
why TCP/IP technology is now getting matured. But I don't think it is "best"
technology. I would call it "old" technology.  About 1983, I had a chance to
design and implement DoD protocols with MIL STD for the U.S. Government.  
I've found a whole bunch of errors on MIL STD specs. I wrote a letter to
DCA about those errors. Still 1990, they are using the same MIL STD specs. 
Do you know why ?? Because they don't have enough money to revise it. Actually,
MIL STD were written by UNISYS under some contract. 

>If Korea and Japan really have thrown out TCP/IP (which I don't believe
>for a second), then they've made a strategic error.  Certainly in
>Europe, the bastion of OSI, they've determined that if you want to
>actually do networking, as opposed to talk about networking, then you do
>it with TCP/IP.  I know of several places in Europe where the phrase
>"IP router" is utterred with reverence and occasionally awe!

Marshall Rose...   

	If you are saying same words to Korea or Japan Government/Industries/
Universities, they are going to laugh. About a year ago, when I had a chance
to go back to Korea, I was invited from several institutions and Korea 
Government Organizations which are dealing with the highest technologies in 
the world. Not many people wanted to talk about TCP/IP. They were already
migrated to OSI world. In these days, I am envolved with the projects with
Euroupe. That's why I was interested in U.K. GOSIP. They are interested in
U.S. "old" TCP/IP technology, but I don't think they will change their 
existing systems for it.   

>Although I'm hopeful that someday OSI might produce competitive
>technologies, I'm not going to hold my breath.  It is not enough to do
>something different, you must do it better, a lot better.  Although
>service for service, the OSI effort is more ambitious than the Internet
>approach, the OSI pseudo-products on the market are, by and large, much
>less functional and robust than their Internet competitors.  It is not
>enough to have a standard for multi-media message handling (X.400), you
>must implement it fully and ubiqiutously in order to displace a
>omnipresent memo-based system (RFC822).  And yet, when I survey the
>X.400 offerings on the market, I still find many lacking features found
>in many of today's RFC822 implementations, and at prices that are truly
>astounding.  The same is true, sadly, for FTAM, and VT.  (And this
>really isn't the fault of the vendors!  OSI technology is extraordinarly
>expensive to produce in terms of time and people.)  I have high hopes
>for OSI Directory Services (X.500), since there really isn't a
>competitor in the Internet suite; but, I fear that political problems
>will make a global Directory improbable.

Some of your statements I agree. Evenif OSI technologies are still 
premature, I don't see 10 years. It's slow sometimes, but the whole world 
is rapidly moving into one OSI world.

>If you are interested in transition technology, there have been papers
>and books printed on this subject for nearly a decade (you might start
>with Green's paper on "Protocol Conversion" in IEEE Trans. on Comm.,
>March, 1986).  There are also some things specific to Internet->OSI
>transition, for example one popular book on OSI devotes about 90 pages
>to the topic.

Thank you for the good reference. Actually, I've enjoyed your "The Open
Book" and ISODE 6.0 source codes more. Again, I think we need to create
a new newsgroup "comp.protocols.migrate.to.iso"  Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: The above opinion was nothing to do with my employer.
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 11:12:00 EDT
From:      <FILLMORE%[email protected]>
To:        [email protected]
Subject:   Multiple IP networks on one Ethernet interface
I have a (perhaps) naive question for the TCP/IP gurus:

I know that the general philosophy in interconnecting IP networks is to use
a router with two interfaces.  I would like a cheaper solution and was wondering
if anyone has got this to work in practice:

We have several organizations with TCP/IP networks, and we have a class B
network number that we divided up into subnetworks (23 bit mask) and allocate
subnetworks to the organizations.  Now the organizations want to talk to each
other.  They are all on Ethernet networks.  I would like to know if any of
the commercially-available TCP/IP packages have the capability of either:

     1)  sending and receiving IP packets for more than one subnetwork
         over the same Ethernet interface.

 or: 2)  routing packets between two or more subnetworks over the
         same Ethernet interface.

We have several spare Ethernet bridges but only one router - a Cisco.
The Cisco documentation implies that each Ethernet interface can be
configured with more than one IP network address but I haven't actually
tried it.  Does this feature have any limitations?
We also run WIN/TCP for VAX/VMS and Control Data's TCP/IP product.  Can
either of these be configured for multiple subnets on one interface?

Thanks for any insight you can provide.

________________________
Bob Fillmore, Systems Software & Communications     BITNET:  [email protected]
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 08:20:47 GMT
From:      [email protected]  (Aloys Roes)
To:        [email protected]
Subject:   Serial line errors and their meaning
I posted this one before but did not see it on the net. Sorry if you get it
twice.

Please help us in solving the following problem:
We have a TCP/IP wide area network in place with 9.6, 14.4 and 64Kbps
lines. For the communication equipment we have standardized on cisco TCP/IP
routers. 
Most lines show quite good performance however a few lines have reasonable 
to high error counts. These error counts are stable and seem independent of 
network load. With these error statistics we asked our telecommunication
people to improve the line quality. Of course they doubted whether the
errors were real. Therefore they started with bit-error-rate tests. These tests
show that the lines are 'perfect' i.e. no single bit or block error in 24
hours. They used different bit patterns but did not get any error.

The next thing we did was to install a PC with a 64K serial interface in
parallel to the cisco router on both ends of one 64K link. The program in
the PC analyzes the packets and monitors the link. And this is where
we really get confused. The PC also finds errors. However these errors are
of a different class and different amounts.

The link that we monitored has an average of 6000 to 10000 errors per day
on one end and a few dozens of errors on the other end. We are now focused on
the end with the high error count;
According to the cisco the errors are mainly frame errors. The PC reports
mainly CRC (or FCS) errors.

Can anyone help us getting this sorted out? What is the best way to tackle
this problem. Is there any equipment that we can put on the line and realy
trust the test-results? Has anyone faced such a problem before? Please respond
to me directly. I will post a summary,

Thanks in advance,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: [email protected]
-- 
     regards,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: [email protected]
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 15:29 MST
From:      [email protected]
To:        [email protected]
Subject:   VMTP
I'm designing a network in which a host running UNIX System 5 and
using TCP-IP over Ethernet sends the same message to 16
workstations.  Rather than send the same message 16 times, would
like to broadcast the message to the workstations only once.
Can't use UDP because the workstations have to acknowledge
receipt of the update.  Do you know if there are any flavors of
VMTP that will do what I need?  

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 12:43:09 EDT
From:      [email protected] (John A. Shriver)
To:        CHAIBP%[email protected]
Cc:        [email protected]
Subject:   desperately need an answer
At the time that RFC was written, people were still trying to run Unix
on machines like PDP-11's.  There were some very fundamental
limitations there, like a severe shortage of address space.  Several
of Dave Clark's cohorts (Larry Allen, Noel Ciappa, and Liza Martin)
were them working on a PDP-11 Unix (V6) TCP/IP.  The only code in the
kernel was half of IP (uniue ID, fragment assembly), enough UDP and
TCP to do receive port demultiplexing, and a psuedo-terminal driver.
The rest of IP and UDP were in libraries, which linked with the
application.  There were two TCP's, one optimized for server Telnet,
and a simpler lockstep one that was for user Telnet, and got used for
many other things as well.  The TCP never got clean enough to be a
library routine, but it was close.  We ran the code here for a while,
but I don't think it's running anywhere anymore.  (Genetic diversity
bites the dust!)  In quite a few ways, it was an excellent pardigm,
better than sockets in some ways, and it required far fewer buffer
copies.  It also used large contiguous buffers.  (No mbufs!)

The other reason not to want to write a TCP in the kernel, aside from
memory space problems, is that debugging inside a kernel is often a
nightmare.  (Single stepping from the console of a PDP-11/45 is not my
idea of fun.)  It is much easier to debug in user space.  Also, other
people can use the machine.

I would guess the reason that the BBN and Berkeley code wound up in
the kernel was that the programmers were more comfortable there.  They
also had the freedom to extend the facilities provided by the kernel
(which your average developer didn't have), and could provide
themselves with the sort of timer facilities they wanted.  The MIT
people were not in the business of "extending" the Unix kernel.

I have no idea if there are any decent debugging facilities in
Streams.  I suspect that most folks doing kernel network code use the
traditional Unix kernel debugging tool: printf()!

Apollo's TCP is not "in" the kernel, so it's not everybody even yet.
Of course, MS-DOS has not kernel, at least not one worth mentioning.

There can be arguments for putting TCP in the kernel for system
security.
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 16:15:30 PDT
From:      [email protected] (Kenneth Adelman)
To:        fillmore%emrcan.bitnet%[email protected]
Cc:        [email protected]
Subject:   Re: Multiple IP networks on one Ethernet interface
> I know that the general philosophy in interconnecting IP networks is to use
> a router with two interfaces.  I would like a cheaper solution and was wondering
> if anyone has got this to work in practice:
>
> We have several organizations with TCP/IP networks, and we have a class B
> network number that we divided up into subnetworks (23 bit mask) and allocate
> subnetworks to the organizations.  Now the organizations want to talk to each
> other.  They are all on Ethernet networks.  I would like to know if any of
> the commercially-available TCP/IP packages have the capability of either:
>
>      1)  sending and receiving IP packets for more than one subnetwork
>	   over the same Ethernet interface.
>
>  or: 2)  routing packets between two or more subnetworks over the
>	   same Ethernet interface.

    Our MultiNet TCP/IP product for VMS can do this; it isn't
documented but customer service can give you the instructions for
enabling it.  We don't want to encourage people to run multiple
network numbers on the same cable because of the potential for
problems with broadcasts.

    Basically we allow you to create two `interfaces' for one ethernet
controller.  Each has its own address, and you can gateway between
them, run routing protocols, etc, just as if you had multiple
controllers on separate cables.  This would allow you to do with (1)
and (2) above.

    If you have any other questions, give me mail or a call at
800-TGV-3440 or 408-427-4366.  If you'd like to try it, we have an
evaluation/trade-in program so I can get a copy right out to you.

						    Kenneth Adelman
						    TGV, Inc.
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 12:31:38 GMT
From:      [email protected] ("John P. McCarthy")
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 terminal server
Pete,

Cisco Systems is in the stages of developing a tn3270 terminal server.
It should be in Beta in a month or so.  The terminal server also
supports SLIP.

 ---------------------------------------------------------------------
| John P. McCarthy              < EOO104 @ URIACC >    U   U RRR  III |
| Data Communications Tech.                            U   U R  R  I  |
| Academic Computer Center                             U   U RRR   I  |
| University of Rhode Island    "That's all Folks!"     UUU  R  R III |
 ---------------------------------------------------------------------

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 18:48:00 CST
From:      "Dan Kellen" <[email protected]>
To:        "tcp-ip" <[email protected]>
Subject:   I need help with subnetting
   I need some routing/subnetting help.

   We have a class B network.  We are not doing subnetting, but have been
   assigning addresses as if we were; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   We have a department that has just aquired several SUN's and want's to
   use one as a gateway to the others.  I gave them IP addresses with a new
   third octet for all of there machines, and an address with the third
   octet of the building they are in, for the second interface on the 
   gateway machine.

   Now comes the problem.  The SUN gateway doesn't gateway!  I can get to 
   the gateway from the main network, but not to/from the other SUN's.

   Since I'm not doing subnetting, the SUN's two interfaces have different 
   IP addresses, the same netmask, but are on two different Ethernet's.  

   I then changed the netmask of the interface to the other SUN's to mask 
   the third octet.  Now the SUN's can talk.  But, the SUN's IP interface 
   to the rest of the network doesn't work.  

   What am doing wrong?


   How about a picture:


        network: 129.61.2.0                network: 129.61.9.0
        netmask: 255.255.0.0               netmask: 255.255.255.0


                                                       +-----+
                                                       |     |
                    /\                           +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Any help appriciated.
   Dan
   [email protected]

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 13:00:48 GMT
From:      [email protected]  (Clement Vaillancourt)
To:        [email protected]
Subject:   Re: IR/microwave links
In article <[email protected]> [email protected] writes:
>
>
>are you using an IR or Microwave link for bridging between two buildings?
>are you happy? owuld you mail me the information you have (including someone
>at the comany to call)?
>
>
>stev knowles
>[email protected]


We are ordering now a microwave link for bridging between two buildings
located 1.2 km apart. We are buying from:

	Microwave Bypass Systems, Inc.
	25 Braintree Hill Office Park,
	Braintree, MA 02184

	contact: Mr. Robert Cuomo at 617-843-8260

I have seen this product operating at Interop89 in San Jose last October.
The total installed cost quoted to us is 39,696 US$ including licensing.

I have heard that IR equipment is also used in Toronto for a distance of
800 meters and it can work if you can see the other building. That IR equipment
is sold by: LCI at 1848 Charter Lane, Suite F Lancaster PA USA 
            +1 717 396 9831.
--
   Clement Vaillancourt,             |   Institut de Recherche d'Hydro-Quebec
   Network Manager                   |        1800 Montee Ste-Julie, Varennes
                                     |             P. Quebec, Canada, J3X 1S1
   Email: [email protected]   |  Tel: 514-652-8238 / Fax: 514-652-8309
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jun 90 01:24:17 -0700
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <[email protected]>
To:        [email protected]
Subject:   Mourning of the passing of the ARPANET
Folks, it appears that the ARPANET has quietly passed away into the annals
of network history.  June 1 was the official cut off date I believe, and I
did some traceroute's to a net 10 host and not even the DDN Core knew
about a route to net 10!  Not even the Mailbridge at BBN in Cambridge.

Script started on Thu Jun  7 01:11:44 1990
cincsac [37]: traceroute -g moffett-fld-mb.ddn.mil 10.0.0.51
traceroute to 10.0.0.51 (10.0.0.51), 30 hops max, 38 byte packets
 1  arc-nas-gw (128.102.16.5)  0 ms  0 ms  0 ms
 2  arc-psn-gw (192.52.195.6)  20 ms  0 ms  20 ms
 3  MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  60 ms  80 ms  60 ms
 4  MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  60 ms !N  40 ms !N  60 ms !N
cincsac [38]: traceroute -g cambridge-mb.ddn.mil 10.0.0.51
traceroute to 10.0.0.51 (10.0.0.51), 30 hops max, 38 byte packets
 1  arc-nas-gw (128.102.16.5)  20 ms  20 ms  0 ms
 2  arc-psn-gw (192.52.195.6)  0 ms  20 ms  0 ms
 3  CAMBRIDGE-MB.DDN.MIL (26.1.0.49)  560 ms  500 ms  640 ms
 4  CAMBRIDGE-MB.DDN.MIL (26.1.0.49)  580 ms !N  480 ms !N  480 ms !N
cincsac [39]: exit
exit

script done on Thu Jun  7 01:12:36 1990

Perhaps a moment of silence is in order...

						Thanks,
						   Milo

PS For those of you not familiar with traceroute, the first shows BMILAMES
sending back a network unreachable message for net 10, and the latter is a 
net unreachable from a gateway at BBN.  The -g option specifies a source
route through the MILNET gateway.  NSFNET doesn't know about it either...
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 21:51:22 -0400
From:      [email protected] (Barry Shein)
To:        [email protected]
Cc:        [email protected]
Subject:   anonymous ftp, and the dangers thereof
>  I don't know that I have any objections to shadow password. WHy give
>the show away? It's like having L.sys or Systems world readable. I
>accept that I can't keep the encryption a secret, so why give the
>encrypted passwords away. I don't see what this has to do with
>security-through-obscurity here.

The objection to shadow password files is that it's an admission that
hiding the file contents is critical to the entire system's security
(if not, why hide them?) Don't argue that it merely "improves" the
existant security, fine, you obviously decide for yourself so you can
believe whatever you like. Multiplicative probabilities aren't
compelling arguments.

If for any reason you suspect that someone has obtained a copy of that
file you have to accept that your system's security has been broached.

You have to view this more in the light of a person with authority
coming to you, asking you what your security relies on, and deciding
that it's critical you now prove that no one has ever walked out of
your center with a copy of the shadow password file, a dump tape, etc.
You've opened yourself up to that (valid) criticism.

The original scheme, keeping it publicly readable, removed a target
for attack (capturing the mere contents.) It relied on good encryption
and good password management. Where either or both of those is lacking
the method is not sufficient.

My tendency would be to improve the encryption methods and password
management and leave it publicly readable.

For better encryption, I've suggested schemes, such as per-site
perturbation of the algorithms. At least that makes it (nearly)
impossible for someone to walk away with a copy of your password file
and crack it on another system.

For password management, password-changers that are continuously being
improved (sources are critical!) to disallow "simple" passwords, and
of course education. If you don't educate users then what's the point?
They'll just hand their passwords out or write them on their white
boards, etc.

L.sys is a problem, but less so because most uucp connections only
allow mail and/or news transport even if someone uses it to break in.

I'm not making light of that, but they really don't get a lot more
with that password file than anyone has who telnets to an SMTP port
(without any password.)  Obviously if it's broached passwords must be
changed, but the potential for real damage via uucp logins is fairly
limited.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | [email protected]
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:22:23 GMT
From:      [email protected]  (John Milburn)
To:        [email protected]
Subject:   Re: SLIP source wanted for HP9000/340
In article <[email protected]> [email protected] (Reiner Petersen) writes:
>In article <[email protected]> [email protected] (Marcel Bernards) writes:
>[] Hello NetReaders,
>[] I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5/7.0.
>We are interested too.
>
>-- reiner

Well, this makes about 50 requests over the last year or so in this forum,
with absolutely no response from hp. The response is no better from
sales reps :-). Is there any hope that slip or cslip will be available
sometime in the near future, or should I just give up and buy a couple
or Sun machines? This is important! Please let us know.

-jem

[email protected]  ...!ucbvax!lbl.gov!JEMilburn
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:32:44 GMT
From:      [email protected]
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Jon Zeeff) writes:
> All this emphasis on turning off tftp and waiting for shadow password 
> files may be clouding the simpler and more effective solution.  Force 
> users to pick good passwords!  Something with some non-alpha 
> characters and mixed case (not the first letter capital).  

Oh, wonderful. Changing 3 bits of information per character to 3.2 bits
per character will slow down the average ``crack'' from fifteen million
encryptions to forty million encryptions. Big deal.

---Dan
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:38:38 GMT
From:      [email protected]
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> Warner Losh writes:
> What is needed is a good guide to how to setup anonymous FTP correctly
> so that nobody can steal any real files.

Yeah. Let's start by criticizing the SRI White Paper's recommendations.
It says ``you may wish'' to remove all non-ftp accounts from the passwd
file inside the ftp directory; it should say ``you should, no matter
what.'' It recommends creation of ~ftp/pub, owner ftp, mode 777; that
should be mode 577. Anyone want to continue this list?

---Dan
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:44:31 GMT
From:      [email protected]
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Peter S. Shenkin) writes:
  [ if passwords are ``good,'' they'll be written down ]
> Not that I have answers....

I have an answer, which I posted to alt.security a few weeks ago but
which was obliterated by cmcl2's alt.* distribution. Here's another
copy.

---Dan

From: [email protected]
Newsgroups: alt.security
Subject: How to get the advantages of all types of passwords
Message-ID: <11082:May1722:49:[email protected]>
Date: 17 May 90 22:49:49 GMT
References: <[email protected]> <[email protected]> <[email protected]>
Reply-To: [email protected] (Dan Bernstein)
Organization: IR
Lines: 23
X-Original-Subject: Re: Improved password cracker - add a sleep()

User-chosen passwords are easily guessable.

Random system-generated passwords are written down all too often.

Expired passwords have been shown to make password guessing easier, and
they don't provide any advantage.

What's the solution? Mix 'n' match. A password has, say, two parts: one
chosen by the user and neither expired nor restricted, one generated
randomly by the system and changed periodically (some sizable fraction
of a year). The first part is NEVER written down; users are told that if
they write down the first part, they'll be drawn and quartered. The
second part is almost certainly written down, typically on a piece of
paper in the user's desk; users are explicitly told that this is okay.

Because the first part of the password is chosen by the user and never
written down, a casual cracker can't find it by just snooping around an
office. Because the second part of the password is chosen by the system,
brute-force cracking will fail miserably.

I proposed this last year (in u-w) but never saw much response.

---Dan
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:50:26 GMT
From:      [email protected]  (Michael O'Dell)
To:        [email protected]
Subject:   Re: desperately need an answer
(1) the limitations aren't that severe because it turns out
implementing TCP/IP isn't as piggish as first thought.
Further, previous experience with putting NCP outside the kernel
for just the suggestes reasons was a cosmic lose in terms of
complexity.

but the important one is....

(2) SPEED!!!!! The last thing in the world you want is a few
extra context switches per packet and per network read/write.
Putting it ouside the kernel almost guarantees extra data copies
as well as the extra context switches.

So, aside from being gratuitously complex and hideously slow, the
idea is great.  

	-Mike
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 21:04 EDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   SUN <-> IBM FTP Performance
I'm looking for performance numbers using the FTP protocol between a SUN
and an IBM mainframe over an ETHERNET.  I don't have all the necessary
machines so I thought I'd appeal to the net.  The ideal situation would
provide numbers for transfers between SUN 4 and a 4341 and for transfers
between a SUN and a 3090 over an ETHERNET.  I'd appreciate it if someone
could run a few GETs and PUTs with the SUN as the client machine for say
a 1 MB file and pass the KBps numbers along to me.  I'd also like a
quick summary of your configuration; e.g., the FTP/TCP products you
used, if you went TCP end to end, if a front end or protocol translator
was involved, if the mainframe I/F was a channel attachment not, etc.
Of course, any words of wisdom explaining the performance for this
configuration are welcome.  Thanks much.

--Jack [email protected]

PS I suppose I could also be interested in SUN-to-9370 rates as well...
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 17:06:11 GMT
From:      [email protected]  ( Graham Jack)
To:        [email protected]
Subject:   State-of-the-art utilities
I'm currently investigating how closely common TCP/IP software matches
the Host Requirements. So far I've only looked at the 4.3BSD sources
and tried out the products from a few suppliers.
It seems that you can swap out the Telnet, BIND, etc supplied with a system and
replace them with P-D versions.
So one of the things I now need to look at is the
'state-of-the-art' versions of various utilities to see how they
shape up. I suppose I'm really interested in versions in current use
rather than 'beta' software being evaluated.

I have gleaned some version numbers from the vanilla 4.3BSD sources and
a quick look at the news groups gave me some hints for later versions.
Can anybody out there help me by filling in the gaps in the
table below and telling me where software is available (by anonymous FTP
or uucp).

	Program		Vanilla		Latest
			(4.3BSD)
	--------	-------		------
	Telnet Client	5.16		????
	Telent Server	5.18		????
	FTP Client	????		????
	FTP Server	4.105		????
	BIND		4.3		4.8.1?
	Sendmail	5.52		5.61+IDA?

BTW: what is 'IDA'?
-- 
Regards,
	    Graham Jack, Data Logic.
	    <[email protected]>
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 18:01:57 GMT
From:      [email protected]  (Michael Meissner)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <19001:Jun616:38:[email protected]>
[email protected] writes:

| In article <[email protected]> Warner Losh writes:
| > What is needed is a good guide to how to setup anonymous FTP correctly
| > so that nobody can steal any real files.
| 
| Yeah. Let's start by criticizing the SRI White Paper's recommendations.
| It says ``you may wish'' to remove all non-ftp accounts from the passwd
| file inside the ftp directory; it should say ``you should, no matter
| what.'' It recommends creation of ~ftp/pub, owner ftp, mode 777; that
| should be mode 577. Anyone want to continue this list?

Actually I prefer to customize the passwd file differently -- you
remove all users who don't have files stored in the ftp archives, and
put *'s for the passwords of all remaining users.  This way, when
somebody does a dir on the files, you have a username to mail to for
questions, and the like, but still does not give out the encrypted
password.
--
Michael Meissner	email: [email protected]		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 18:19:57 GMT
From:      [email protected]  (Bill Wisner)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
The passwd file in my anonymous FTP heirarchy has all encrypted
passwords replaced with asterisks. What's the problem?

Bill Wisner <[email protected]> Gryphon Gang Fairbanks AK 99775
"Remember, some net.personalities are basically insane."
-- Karl Lehenbauer <[email protected]>
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 19:00:53 GMT
From:      [email protected] (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: AT&T's RFS needs a TCP port number
In article <[email protected]>, [email protected] writes:
> 
> Since AT&T doesn't seem on the ball about registering an official TCP/IP
> port number for RFS, how can we get this going?

I've been informed that this is indeed in progress, and was even
before this posting.

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 19:11:10 GMT
From:      [email protected]  (J. Nelson Howell)
To:        [email protected]
Subject:   Re: Interesting uses of networking
In article <[email protected]> [email protected] (Aaron Wohl) writes:

        ...

>Glen Marcy ([email protected]) hacked a finger server on a tops20 to
>connect to an rs232 line to the airconditioning computer on the roof.
>One could finger [email protected]
>
>Someone is cs (try laurence [email protected]) wired up the coke machine.
>You could finger [email protected] and see how cold the coke was.

Actually, it did much more.  It would tell you when the machine was filled,
the temperature of each flavor, the last purchase of each flavor, and a few
things I have forgotten.  It was quite impressive to undergrads that were
trying to figure out the basics of networking (myself included at the time).

Come to think of it, it's still pretty impressive :-)


J. Nelson Howell                       | System Programmer
[email protected]  Internet | Krannert Graduate School of Management
[email protected]                BITNET   | Purdue University
                                       | West Lafayette, IN
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 19:23:59 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
>From: [email protected] (Marshall Rose) wrote:

>I think you've missed April Fools' Day by about 2 months and 4 days!
>But, if you were serious, then you are probably 9 years, 9 months, and
>26 days premature in sending your message.

Yes. I am so serious. We need to create a new newsgroup "comp.protocols.
migrate.to.iso". For instance, recently I've designed and implemented RDA 
(ISO/IEC DP 9579-1) on top of SunLink OSI and TCP/IP with RFC 1006 on my 
SPARCstation 1. Actually, I've embedded it into ISODE 6.0.  However,
a lot of customers wanted to put it on top of lpp (RFC 1085). I have a trouble
with finding those specific bridges between RFC 1085 and "pure" OSI stack.
If we create those new newsgroup, then we can have an info on migration from
"old" TCP/IP technology, SNA, or other protocols to "new" OSI technology.
As far as I know, application gateways, transport gateways, network tunnels,
protocol tunnels, etc are the only primitive methods for the migration. 
Actual environment needs higher technology.

>The Internet suite of protocols is only now coming into its own.  This
>"old" technology is quite vibrant and has a lot of life flowing into it.
>It is also the only thing that works today across multiple vendor lines.
>Further, when meaningful comparisons can be made, it also seems to be
>best technology around, as evidenced by its wide deployment and ever-maturing
>market.

I don't quite agree with it. As I've explained, since the U.S. Government is
getting poorer, they can not afford to replace the "old" technology. Moreover,
they don't want have an error especially under tactical environments. That's
why TCP/IP technology is now getting matured. But I don't think it is "best"
technology. I would call it "old" technology.  About 1983, I had a chance to
design and implement DoD protocols with MIL STD for the U.S. Government.  
I've found a whole bunch of errors on MIL STD specs. I wrote a letter to
DCA about those errors. Still 1990, they are using the same MIL STD specs. 
Do you know why ?? Because they don't have enough money to revise it. Actually,
MIL STD were written by UNISYS under some contract. 

>If Korea and Japan really have thrown out TCP/IP (which I don't believe
>for a second), then they've made a strategic error.  Certainly in
>Europe, the bastion of OSI, they've determined that if you want to
>actually do networking, as opposed to talk about networking, then you do
>it with TCP/IP.  I know of several places in Europe where the phrase
>"IP router" is utterred with reverence and occasionally awe!

Marshall Rose...   

	If you are saying same words to Korea or Japan Government/Industries/
Universities, they are going to laugh. About a year ago, when I had a chance
to go back to Korea, I was invited from several institutions and Korea 
Government Organizations which are dealing with the highest technologies in 
the world. Not many people wanted to talk about TCP/IP. They were already
migrated to OSI world. In these days, I am envolved with the projects with
Euroupe. That's why I was interested in U.K. GOSIP. They are interested in
U.S. "old" TCP/IP technology, but I don't think they will change their 
existing systems for it.   

>Although I'm hopeful that someday OSI might produce competitive
>technologies, I'm not going to hold my breath.  It is not enough to do
>something different, you must do it better, a lot better.  Although
>service for service, the OSI effort is more ambitious than the Internet
>approach, the OSI pseudo-products on the market are, by and large, much
>less functional and robust than their Internet competitors.  It is not
>enough to have a standard for multi-media message handling (X.400), you
>must implement it fully and ubiqiutously in order to displace a
>omnipresent memo-based system (RFC822).  And yet, when I survey the
>X.400 offerings on the market, I still find many lacking features found
>in many of today's RFC822 implementations, and at prices that are truly
>astounding.  The same is true, sadly, for FTAM, and VT.  (And this
>really isn't the fault of the vendors!  OSI technology is extraordinarly
>expensive to produce in terms of time and people.)  I have high hopes
>for OSI Directory Services (X.500), since there really isn't a
>competitor in the Internet suite; but, I fear that political problems
>will make a global Directory improbable.

Some of your statements I agree. Evenif OSI technologies are still 
premature, I don't see 10 years. It's slow sometimes, but the whole world 
is rapidly moving into one OSI world.

>If you are interested in transition technology, there have been papers
>and books printed on this subject for nearly a decade (you might start
>with Green's paper on "Protocol Conversion" in IEEE Trans. on Comm.,
>March, 1986).  There are also some things specific to Internet->OSI
>transition, for example one popular book on OSI devotes about 90 pages
>to the topic.

Thank you for the good reference. Actually, I've enjoyed your "The Open
Book" and ISODE 6.0 source codes more. Again, I think we need to create
a new newsgroup "comp.protocols.migrate.to.iso"  Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: The above opinion was nothing to do with my employer.
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 20:33:37 GMT
From:      sdd.hp.com!zaph[email protected]ucsd.edu  (Mike McCann)
To:        [email protected]
Subject:   Printing from a PC to a DECserver printer
I am looking for a piece of software that will allow a PC with an
Ethernet card to print to a printer that is attached to a DECserver.

I would like to make this transparent to the user by having LPT1:
remapped so that it prints automatically to the printer on the
DECserver.

I welcome any suggestions or comments on how this could be done.
Spooling on a UNIX or VMS machine would be fine as well.

Thanks for the help in advance,

-- 
Mike McCann       (803) 656-2721   Internet = [email protected] 
Engineering Computer Operations      Bitnet = [email protected]
Clemson University
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thu 7 Jun 90 01:13:13-EDT
From:      Dan Lynch <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected]
Subject:   Re: toll restrictors
Kraig,  You bring up a very cogent point>  To wit, does a particular OS
have the flexibility to control access on a per user basis to particular
system resources. In the case of current interest you are interested
in network access.  In the late 70's I was associated with a computer
service company (Tymshare) and we had users who cam in via Tymnet and
users who cam in via Arpanet and we had to be able to permit/deny
access on a per user basis to "the other network".  We put th ehooks 
for this into our operating system, Tenex (the precursor of TOPS20).
It was a simple hack to put in the OS.  The only hair/pain was to
then keep the list of permissions updated whenever we created a new user.

IN fact, I have found that the mechanism part(s) of security and access
control are very easy for the OS enforcement part.  The huge and ugly 
part has to do with the administrative part of actually creating
and modifying allthe lists of permissions on a per entity basis.

I'm sure Unix could be hacked a bit to do the same as Tenex did many
years ago.

Dan
-------
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 22:34:01 GMT
From:      [email protected]  (Keith Brown)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
]I've been working on TCP/IP almost 10 years now. I am 
]so tired of it. Since the U.S. Government is getting so poor, they cannot 
]afford to change their environments so quickly. Only thing they can think of
]"Security, security !!", I guess. 
]
]	I had a chance to go back to Korea about a year ago. Not many people  
]wanted to talk about TCP/IP. They think it is now pretty old technology.
]Wealthy countries like Korea, Japan, they quickly threw out the old TCP/IP
]technology. I know Korea has sucked all of the highest technologies from all 
]over the world. 

I would just like to point out that marker pens should only be used for
writing on whiteboards, not for sniffing.....
----------------------------------------------------------------------------
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
San Jose, California 95131                       Net:   [email protected]
----------------------------------------------------------------------------
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jun 90 10:45:51 -0700
From:      Marshall Rose <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1
I think history is being a little loosely interpreted here.  The
committee working on X.400 was the first to define an OSI application.
As such, they defined X.409(84).  When other OSI applications began
being defined, the abstract syntax/transfer syntax (ASN.1 and BER) were
split out into ISO8824/ISO8825 and X.208/X.209.  It is true that the
original use of the ASN.1 stuff was MHS, but ASN.1 was not invented
solely for that purpose--the MHS people just happened to be in the
position to need it first.

The strength of something like ASN.1 is its ability to describe a wide
range of data structures using a machine-parsable notation.  One of the
design goals of the OSI people involved was to make sure that it did not
limit the precision of the things being described.  Hence, INTEGERs
needn't be of fixed length, etc.  A side-effect of this is that you need
an encoding algorithm which can accommodate variable length data.

In theory, you can use many different algorithms to encode things
defined using ASN.1, but at present, only one such algorithm has been
standardized, the Basic Encoding Rules.  The reference by Huitema you
are referring to is a second algorithm defined at INRIA, based on Sun's XDR.

The motivation for using ASN.1 in the SGMP and SNMP is simple:
industry has already decided on the lingua franca of the 90's (ASN.1/BER),
and it is counter-productive to invent

		  yet-another-description-and-encoding-standard

So, the goal was to select a small, workable subset that could be
implemented easily, and allowed for some useful optimizations.  Then, if
an implementor is really concered about efficiency, then the routines
can be done by hand with great care. (Probably the most important part
is to have efficient encode/decode support for integers, which
interestingly enough is where the performance characteristics of BER and
XDR differ the most.  By optimizing in once place, you can dramatically
improve the speed of your encoder.)

Using the BER, rather than a non-standard algorithm, over an optimized
ASN.1 was chosen because regardless of the availability of alternate
encoding algorithms, anyone implementing ASN.1 still has to implement
the BER since that's what all ASN.1-capable applications use.  So, if
you are going to ask a vendor to implement something else for their
ASN.1 library to use with application X, you have essentially told them
to do twice as much work.

Since the time of the initial SGMP work, experience has shown that if
you limit use of ASN.1 carefully, you can implement an efficient BER
mapping, this seems to be the most reasonable compromise.

/mtr
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 23:25:08 GMT
From:      [email protected] (The Grey Wolf)
To:        alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Jon Zeeff) writes:
>All this emphasis on turning off tftp and waiting for shadow password 
>files may be clouding the simpler and more effective solution.  Force 
>users to pick good passwords!  Something with some non-alpha 
>characters and mixed case (not the first letter capital).  
>
>Neither turning off tfpd or even shadow passwords will protect you from 
>local users or people who used to have root.

I'm rather new to some of this stuff, so please excuse my ignorance.

To what extent does one disable tftp (or did the original user mean
anonymous ftp)?

If, indeed, one disables tftp, why is this done?  tftp is about the only
way to boot a machine over the network if one needs to reformat the local
disk, and we don't have QIC drives or 9-track drives for every machine, and
hooking them up/disconnecting them is a pain in the ass.  I'd much rather
not have to move the workstation if I can avoid it.

Please don't flame me about hardware or the inadequacies of our setup;
it would be a waste of time and it would completely beg the question.

-- 
MORALITY IS THE BIGGEST DETRIMENT TO OPEN COMMUNICATION.
/earth: minimum percentage of free space changes from 10% to 0%
should optimize for space^H^H^H^H^Hintelligence with minfree < 10%

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 00:48:00 GMT
From:      [email protected] ("Dan Kellen")
To:        comp.protocols.tcp-ip
Subject:   I need help with subnetting

   I need some routing/subnetting help.

   We have a class B network.  We are not doing subnetting, but have been
   assigning addresses as if we were; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   We have a department that has just aquired several SUN's and want's to
   use one as a gateway to the others.  I gave them IP addresses with a new
   third octet for all of there machines, and an address with the third
   octet of the building they are in, for the second interface on the 
   gateway machine.

   Now comes the problem.  The SUN gateway doesn't gateway!  I can get to 
   the gateway from the main network, but not to/from the other SUN's.

   Since I'm not doing subnetting, the SUN's two interfaces have different 
   IP addresses, the same netmask, but are on two different Ethernet's.  

   I then changed the netmask of the interface to the other SUN's to mask 
   the third octet.  Now the SUN's can talk.  But, the SUN's IP interface 
   to the rest of the network doesn't work.  

   What am doing wrong?


   How about a picture:


        network: 129.61.2.0                network: 129.61.9.0
        netmask: 255.255.0.0               netmask: 255.255.255.0


                                                       +-----+
                                                       |     |
                    /\                           +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Any help appriciated.
   Dan
   [email protected]

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 01:45:48 GMT
From:      [email protected]  (Patrick Johnston)
To:        [email protected]
Subject:   Re: TCP/IP Between PCs and Mainframes...What Physical Layers?
In article <[email protected]> [email protected] (Will E Estes) writes:
>Using IBM's mainframe TCP-IP implementations and OS/2 Extended Edition's
>TCP/IP, what physical layers can be used?  I assume Ethernet at minimum,
>but what about token ring, and what about SDLC since that is how the
>vast majority of PCs are linked to mainframes?  Also, what about the case
>where a PC goes through a gateway that emulates a 3174 and is connected
>by modem to a 3725?

IBM's TCP/IP supports ethernet in three ways:

1. 8323 (industrializd PC AT with an ungerman bass ethernet card)
2. 3172 (PS/2 386 version of the 8232 - internal ethernet card)
3. 9370 802.3 card with communications processor

You can also use any device that supports the CETI channel protocol
(such as BTI's box or Interlink's 3722)


Token ring is supported in the same three ways.  There has been no
announced support for the 3174 TIC option in either the 3174L or 3174R
controllers.  There is no announced support in the 3270 workstation
software version 3 (the stuff that connected a PC to a 3745 via SDLC)
and there is no announced support for OS/2 comm manager for IBM's TCP/IP
software.

IBM's TCP/IP software can communication with another mainframe via SDLC
lines (via LU0). The above ways are the only ways that I know on getting
TCP/IP out of an IBM mainframe.  

Hmmm... UUCP to a mainframe via a 3745....  I'll have to bring
that up at my next staff meeting....
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 02:18:00 GMT
From:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   desperately need an answer


Clark, in his RFC 817, said that kernel implementation
of TCP/IP would subject to many system limitations and
suggested that only part of TCP/IP should be placed in
the kernel, leaving the rest in the user processes.

Now, what I don't understand is that why everybody still
put the entire TCP/IP in the kernel - AT&T system V,
Sun BSD Unix and many others all does just that. Does
that mean that those limitations are never faced by them
or that they have actually took his advice but provided the
interfaces to the user processes in a way that gives
them the illusion of interfacing with the kernel ?

Desperately need an answer on that ! Please give me
an answer if you do have one.

Chai

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jun 90 13:58:40 -0700
From:      [email protected] (Steven M. Schultz)
To:        [email protected], [email protected]
Cc:        [email protected], [email protected]
Subject:   Re:  abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
Dennis:

>From [email protected] Thu Jun  7 13:16:46 1990
>>"Steven M. Schultz" <[email protected]> writes:
>>	just a "thought" - if the (shadow)file is non-world readable and the
>>	system is administered "correctly" then why bother with
>>	encryption at all ;-)
>
>   Just in case one of the system admins is a bad guy or becomes a
>bad guy.  I have three passwords for 30+ systems of which I only
>administrate 12 of them.  If my password was available in the clear to
>system administrators on the other machines, they would have my passwords
>to all my accounts which is not a good idea.  Also, what do you do when
>you fire a system administrator for bad conduct?  If he had access to
>those clear passwords, every password would have to be changed.

	i thought i was being only semi-serious...  guess i didn't make that
	clear enough.

	the thought at the time was that the file being non-world readable
	excludes any one BUT a sysadmin from even knowing if there is
	a password present, much less whether it's encrypted or not.

	besides the sysadmin is being trusted not install password snarfing
	versions of programs, isn't he?

	after obtaining (or already posessing) sufficient privs to
	read the "non-world readable file" a person (sysadmin or badguy)
	neither knows nor cares what passwords are - at that point the
	person can do anything he wants to.

	do the other sysadmins have sysadmin privs on the system(s) you 
	administer? if not, then they wouldn't be able to read the 
	"non-world readable" file in the first place.  if they do have 
	privs on your systems, then they can do anything you can and 
	don't need to know the passwords anyhow.

	you mean you don't change passwords when sysadm types leave (especially
	when they're TOLD to leave)?  when someone is as trusted a capacity
	as that leaves (on bad terms especially) i'd think that there'd be
	a fair amount of concern over possible dummy privd account left
	behind, and the like.

	no, i'm not advocating removal of encryption.

	Steven
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 06:25:23 GMT
From:      [email protected]  (Joe Smith)
To:        [email protected]
Subject:   Ancient articles re-appearing.
This article showed up on my system.  Any idea who's machine is in a time warp?

From tymix!oliveb!logicon.com!nosc!crash!ncr-sd!sdd.hp.com!uakari.primate.wisc.
edu!aplcen!unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu
!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!husc6!hscfsas1!chrome Wed Jun 
 6 23:14:24 PDT 1990
Path: tardis!tymix!oliveb!logicon.com!nosc!crash!ncr-sd!sdd.hp.com!uakari.prima
te.wisc.edu!aplcen!unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.
cuny.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!husc6!hscfsas1!chrome
Newsgroups: alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject: Re: anonymous ftp, and the dangers thereof
Message-ID: <[email protected]>
References: <[email protected]>
Sender: [email protected]

Looks like the original date was 18-Apr-90.
-- 
Joe Smith (408)922-6220 | SMTP: [email protected] or [email protected]
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C41    | BIX: smithjoe | 12 PDP-10s still running! "POPJ P,"
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jun 90 11:08:32 EDT
From:      Bob Stewart <[email protected]>
To:        [email protected], [email protected]
Subject:   X Windows and TCP/IP on the Macintosh
Dear Generous Suppliers of Free Advice,

I'm using NCSA Telnet on my Macintosh to talk to a Unix system so I can
communicate with the world.  It's connected through AppleTalk to a Gator Box.
I'd like to have a more direct connection for mail, FTP, etc., as well as 
X Windows access.

We're looking into White Pine Software's eXodus, which implements X Windows
over a communication base such as Alisa Systems' TSS for DECnet or Apple's
MacTCP for the Internet.  I'd like to hear from people who've tried that or
who know anything interesting about it.  If I have MacTCP, can I run FTP,
Telnet, eXodus, and such just as if I was on a Real :-) System?  If so, can
they all run at once?  White Pine tells me that eXodus/MacTCP and NCSA Telnet
are mutually exclusive.  If anyone from Apple or White Pine cares to respond,
I won't consider it as a commercial message.

Thanks in advance for the help.

	Bob

-----------
Bob Stewart ([email protected])
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 18:18 H
From:      <CHAIBP%[email protected]>
To:        [email protected]
Subject:   desperately need an answer

Clark, in his RFC 817, said that kernel implementation
of TCP/IP would subject to many system limitations and
suggested that only part of TCP/IP should be placed in
the kernel, leaving the rest in the user processes.

Now, what I don't understand is that why everybody still
put the entire TCP/IP in the kernel - AT&T system V,
Sun BSD Unix and many others all does just that. Does
that mean that those limitations are never faced by them
or that they have actually took his advice but provided the
interfaces to the user processes in a way that gives
them the illusion of interfacing with the kernel ?

Desperately need an answer on that ! Please give me
an answer if you do have one.

Chai

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 09:29:50 GMT
From:      [email protected]  (Raymond van der Laan)
To:        [email protected]
Subject:   datagrams and non-blocking sockets ==> PROBLEM
I have written a network interface on a Sun 386 machine using socket
based IPC. The virtual circuit stuff works fine, but I have a problem
with the datagram part.

Because I want to be able to identify the sender of the datagram,
I let the sender bind its socket to a portnumber (which is well-known
to both parties). When I use the recvfrom call on the receiver's side,
I can retrieve the portnumber and the hostmachine, so I know who sent
the DG. No problems so far.

However, because I do not want to wait forever if there is no dg sent at
all, I use the ioctl call on the receivers side to mark the socket non-
blocking (FIONBIO). When I do this, the binding done by the sender has no
effect. Instead, the system binds the socket to some other portnumber, so
the receiver doesn't know who sent the DG.
(I use the same ioctl call for VC's, but this call is made after the
VC is established.)

What's happening? If anyone knows more about this, please let me know.


+---------------------------------------------------------------------------+
| Raymond van der Laan                                                      |
| Mediasystemen B.V.                                                        |
| Holland                                                                   |
+---------------------------------------------------------------------------+
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 10:32:41 GMT
From:      [email protected]  (John Pettitt)
To:        [email protected]
Subject:   Name server help wanted
We have a mixed network of PC's and workstations running TCP/IP
and currently using /etc/hosts to resolve ip addresses.  I will
shortly be bridging to two remote nets and would like to move
to a name server based system.

Can anybody point me at a simple guide to setting up and maintaining
name servers ?  We will eventually be conneting to one of the commercial
IP nets (which ever one gets to the UK first !) and would like to get
things right now while the net is still only 20 systems.


-- 
John Pettitt, Specialix International, 
Email: [email protected] Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781
Disclaimer: Me, say that ?  Never, it's a forged posting !
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 17:36:11 PDT (Thu)
From:      [email protected] (Karl Auerbach)
To:        [email protected]
Subject:   Efficiency (or lack thereof) of ASN.1
ASN.1 doesn't try to limit itself in any way.  And that makes it a CPU
hog.  There are zillions of applications where the data range is
limited and the overhead of ASN.1 simply isn't reasonable.

I've optimized and optimized my ASN.1 tools and I find that my SNMP
(which occupies on the order of 20K bytes) could be cut in half if
ASN.1 were replaced by something more like XDR.  And the performance
would be significantly improved.  The problem is that ASN.1 requires
the CPU to examine each and every character.

(I've found that the #1 bottleneck is handling the length field.  #2
bottleneck is handling multi-byte tags [even though they occur with
extreme in-frequency].  These sort of things occuply only a few lines
of C, but they tend to get executed a lot and tend to generate rather
many machine instructions per line of C.)

ASN.1 is the perfect example for the cliche "If all you have is a
hammer, everything looks like a nail."

				--karl--
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 11:59:08 GMT
From:      [email protected] (Stephan Biesbroeck)
To:        comp.sys.ibm.pc.rt,comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   IP over x25 between IBM PC/RT and cisco

I have an IBM PC/RT with an X25 board in it. I also have the software
of IBM for running IP above X25.
What I want to do is the following : get an IP connection between my PC/RT
and a cisco-router over an x.25 network.
Is this possible? Has anybody already done this?

Any help will be appreciated of course. 


Send your suggestions, directions, remarks, .... to
[email protected] or [email protected]
[email protected] 


----------------------------------------------------------------------------
Stephan Biesbroeck                        Katholieke Universiteit Leuven
Tel : +32/16/20.10.15(x3602)              Dept. of Computer Science
telex : 23674 KULEUV B                    Celestijnenlaan 200A
fax : +32/16/20.53.08                     B - 3030 Leuven
email : [email protected]         Belgium
        [email protected]
        [email protected]
----------------------------------------------------------------------------

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jun 90 16:19:03 EDT
From:      "Dennis G. Rears (FSAC)" <[email protected]>
To:        "Steven M. Schultz" <[email protected]>
Cc:        [email protected], [email protected]
Subject:   Re:  abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
"Steven M. Schultz" <[email protected]> writes:
>
>>From: [email protected]  (Bill Stewart erebus.att.com!wcs)
>>References: <[email protected]>, <[email protected]>
>>
>>	/etc/passwd has become the traditional location for user-info
>>	other than passwords, so of course it needs to be kept,
>>	but I agree with the shadow-password approach that puts 
>>	(encrypted) passwords in a non-world-readable file.
>
>	just a "thought" - if the (shadow)file is non-world readable and the
>	system is administered "correctly" then why bother with
>	encryption at all ;-)

   Just in case one of the system admins is a bad guy or becomes a
bad guy.  I have three passwords for 30+ systems of which I only
administrate 12 of them.  If my password was available in the clear to
system administrators on the other machines, they would have my passwords
to all my accounts which is not a good idea.  Also, what do you do when
you fire a system administrator for bad conduct?  If he had access to
those clear passwords, every password would have to be changed.

Dennis
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 13:23:18 GMT
From:      [email protected]  (Anton Rang)
To:        [email protected]
Subject:   tftp (was Re: anonymous ftp, and the dangers thereof)
In article <[email protected]> [email protected] (The Grey Wolf) writes:
>To what extent does one disable tftp (or did the original user mean
>anonymous ftp)?

  At a minimum, you should restrict either which hosts can access tftp
on a given machine, or which files tftp can access.  The problem is
that tftp, as distributed, lets anyone access any publicly-readable
file, and lots of important files (like /etc/passwd) are publicly
readable.  (In other words, having tftp enabled allows dictionary
attacks to be tried without needing an account on the remote machine.)

  This is my understanding of the matter, at least; feel free to
correct any misapprehensions.

		Anton
   
+---------------------------+------------------+-------------+
| Anton Rang (grad student) | [email protected] | UW--Madison |
+---------------------------+------------------+-------------+
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 14:19:57 GMT
From:      swrin[email protected]ucsd.edu
To:        [email protected]
Subject:   WIN/TCP 5.1 programming question
Hi,

I have an account that I would like to limit access to based on IP address. 
This is under VMS 5.3-1 and WIN/TCP 5.1 (though a Multinet program should work
too).  My idea is that the LOGIN.COM (or an executable run in it) would find
out the IP address that the TELNET is from and then screen based on that.  If
anybody can give me an example program that figures out the IP address, I would
appreciate it.

Thanks,

================================================================================
Billy Barron                  Bitnet : [email protected]
VAX system manager            THENET : NTVAX::BILLY
University of North Texas   Internet : [email protected]
                                SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 14:58:34 GMT
From:      [email protected]  (John F. Haugh II)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <19105:Jun616:44:[email protected]>, [email protected] writes:
> Because the first part of the password is chosen by the user and never
> written down, a casual cracker can't find it by just snooping around an
> office. Because the second part of the password is chosen by the system,
> brute-force cracking will fail miserably.

The flaw in your assumption is the sentence "Because the second part of
the password is chosen by the system, brute-force cracking will fail
miserably."  The problem is that the "hard" part is permitted to be written
down anywheres, or even encouraged to.  This reduces the problem to
finding out the "easy" part of the password.

If this system uses two separate passwords, each given in turn, I try
cracking the "easy" password whenever prompted, since I am always able
to respond with the "hard" password I just found written on your desk
blotter.

If this system interweaves the two parts, I try cracking by starting
with the "hard" part and interweaving my guesses.  This is only
comlicated by the number of possible positions my "easy" part can be
interwoven into.  I would presume that avoiding too much complication
would greatly limit the number of positions, further weakening this
scheme.

> I proposed this last year (in u-w) but never saw much response.

I hope you like my response ;-)
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: [email protected]

                                            Proud Pilot of RS/6000 Serial #1472
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 15:12:55 GMT
From:      [email protected]  (John Robert LoVerso)
To:        [email protected]
Subject:   Re: tftp (was Re: anonymous ftp, and the dangers thereof)
And don't be fooled by the fact that the TFTP protocol doesn't include
a list-directory call.  The BSD tftpd will allow [publically readable]
directories to be read, and so a clever user tftp program could use this
to implement an "ls"-style listing.  This can give away the names of
subdirectories you might have in your tftp-area (if you are running
a "secure" tftpd that does a chroot), or let the people walk your
whole filesystem, even if they don't know its layout before hand.

A trivial change to tftpd would prevent the reading of all but plain
files.

John
-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140 x284
[email protected]			Annex Terminal Server Development Group
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 16:34:37 GMT
From:      [email protected]  (Amanda Walker)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In article <[email protected]>, [email protected] (Kwang Sung) writes:
> If you are saying same words to Korea or Japan Government/Industries/
> Universities, they are going to laugh.

They haven't so far.  TCP/IP is used by many Japanese universities and
industry leaders for the reason that it works and is available right now.
They may be doing research into OSI and MAP/TOP, but they still use TCP/IP
to get their work done.

> I was invited from several institutions and Korea 
> Government Organizations which are dealing with the highest technologies in 
> the world. Not many people wanted to talk about TCP/IP. They were already
> migrated to OSI world.

If they have installed and operational OSI networks, with similar scale,
performance, and quality of service as U.S. and European TCP/IP networks,
then it's time I scheduled a trip to Korea to see them.

I wonder how they managed it while the ISO is still arguing with itself...

> It's slow sometimes, but the whole world is rapidly moving into one OSI
> world.

It doesn't look that way from what I've seen.  My company is a TCP/IP vendor.
The fastest growing part of our market is overseas--institutions all over
the world are installing and expanding TCP/IP networks, sometimes replacing
attempts to use OSI.

OSI has some very important advantages over TCP/IP, but it is still quite
immature technology, and I think that it's a little early to plan
large-scale migration from TCP/IP.  For discussion, though, you can always
use 'comp.protocols.iso', which can probably handle the volume for a
while...

--
Amanda Walker, InterCon Systems Corporation
--
"If we don't succeed, then we run the risk of failure."  -- Dan Quayle
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 16:37:38 GMT
From:      [email protected]  (Amanda Walker)
To:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
In article <[email protected]>, [email protected] (Karl Auerbach)
writes:
> In my SNMP code, my profilers indicate that an
> overly large portion of the of cycles are spent in the ASN.1
> encoder/decoder.  Maybe my code is inefficient -- although I doubt it.

You might want to look at it again.  The quite restricted variant of ASN.1
that is used in SNMP can actually be pretty quick to parse.  Most of the
publically available ASN.1 parsers that I have seen are overly complex...

--
Amanda Walker, InterCon Systems Corporation
--
"If we don't succeed, then we run the risk of failure."  -- Dan Quayle
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 17:07:04 GMT
From:      sw[email protected]ucsd.edu  (Russ Nelson)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In article <[email protected]> [email protected] (Kwang Sung) writes:

   	If you are saying same words to Korea or Japan Government/Industries/
   Universities, they are going to laugh.

I just went into 'irc' (Interactive Relay Chat), and did a '/links' command.
The hosts that are linked into irc are listed below.  Not only is Europe
well represented, so is Japan.  Perhaps you're right about OSI, but when
people want to internetwork today, they get on the Internet.

noc.belwue.de (BELWUE (Stuttgart), West Germany)
uni-ulm.de ([titania.mathematik.uni-ulm.de] University of Ulm,)
uni-kl.de ([popper.informatik.uni-kl.de] [131.246.8.80]Univer)
rwth-aachen.de ([cip-s01.informatik.rwth-aachen.de] [192.35.229.11)
ira.uka.de ([iraun1.ira.uka.de] University of Karlsruhe, FRG)
zephyr.cair.du.edu (University of Denver's International Server)
s.ms.uky.edu (University of Kentucky)
xanth.cs.odu.edu (Magical land of Xanth Server)
suna7.cs.uiuc.edu (University of Illinois at Urbana Backup)
sunb7.cs.uiuc.edu (University of Illinois at Urbana Backup)
garfield.mit.edu (MIT Project Athena, Massachusetts, U.S.A.)
diamond.bbn.com (The Server at the End of the World)
chaos.cs.brandeis.edu (Brandeis University, Waltham, MA 2.4)
wharfin.wpi.edu (WPI TEST server running IRC II v2.4.1)
bucse.bu.edu (Boston University, Boston, MA 2.4.1)
eniac.seas.upenn.edu (University of Pennsylvania, Philadelphia, PA)
beach.cis.ufl.edu (University of Florida Server)
slopoke.mlb.semi.harris.com (Harris Semiconductor, Melbourne FL, US
fysaj.fys.ruu.nl (Rijks Universiteit Utrecht, the Netherlands)
assari.tut.fi (Tampere University of Technology, Finland)
otax.tky.hut.fi (Student Body of Helsinki University of Technology)
cs.hut.fi ([sauna.hut.fi] Helsinki University of Technology, )
lut.fi (Lappeenranta University of Technology, Finland)
tolsun.oulu.fi (Experimental IRC Server at University of Oulu, Fin)
kreeta.helsinki.fi (University of Helsinki, Finland <IRC 2.4.1>)
joyx.joensuu.fi ([128.214.14.2] University of Joensuu, Finland)
jyu.fi (University of Jyvaskyla, Finland)
tel4.tel.vtt.fi ([130.188.12.4] VTT--Technical Research Centre of F)
nada.kth.se ([130.237.222.50] Royal Institute of Technology, St)
laila.lysator.liu.se (Lysator CC at Link|ping University, Sweden)
flute.er.sintef.no (ELAB-RUNIT, U. of Trondheim, Norway <2.2msa.4>)
solan4.solan.unit.no (Norwegian Institute of Tech., Trondheim N)
svarte.uio.no (University of Oslo, Norway <2.4>)
adagio.fy.chalmers.se ([129.16.6.200] Chalmers Tekniska Lekskola)
shai.sics.se ([192.16.123.226] Swedish Institute of Computer Sci)
lso.win.tue.nl (Experimental IRC-Server, Eindhoven, Holland)
slice.ooc.uva.nl ([192.42.115.1] Universiteit van Amsterdam, The Ne
giza.cis.ohio-state.edu (Ohio State University, Columbus)
schubert.psu.edu (Penn State NeXTlab IRC server)
galileo.apo.nmsu.edu (Apache Point Obs.)
cwns1.INS.CWRU.Edu (CWRU IRC Server)
wpi.edu ([wpi.WPI.EDU] WPI's Server (others are cheap imita)
vela.acs.oakland.edu (Oakland University, Rochester, MI, USA)
washington.andrew.cmu.edu (A server named George(2.4))
unix.cis.pitt.edu (University of Pittsburgh Server)
astsun.astro.Virginia.EDU (University of Virginia 2.4)
group-w.uchicago.edu (University of Chicago - Astro)
kentmath.math-cs.kent.edu ([kentmath.kent.edu] Computer Science Department, K)
oddjob.uchicago.edu (University of Chicago - Astro)
ux.acs.umn.edu (University of Minnesota, Minneapolis, MN)
medusa.cs.purdue.edu (Chief's Server)
uxc.cso.uiuc.edu (University of Illinois at Urbana (V2.4))
uni-erlangen.de ([faui43.informatik.uni-erlangen.de] Uni Erlangen)
guug.de ([192.48.231.3] GUUG Muenchen,West-Germany)
TU-Muenchen.de ([sunsystem1.informatik.tu-muenchen.de] TU Munich, )
tavi.rice.edu (Rice University)
iroquois.utdallas.edu ([129.110.10.12] Univ. of Texas at Dallas)
pkg.mcc.com ([128.62.40.1] Group Talisman server at MCC, Austin)
taltta.hut.fi (Helsinki University of Technology)
GRASP.CIS.UPENN.EDU (U of Penna. TiTo Server, Philadelphia, PA, USA)
emil.csd.uu.se (CS Dept., Uppsala Univ., Sweden <2.4.1>)
mizar.docs.uu.se (Uppsala University Server (DoCS))
uceng.uc.edu (University of Cincinnati Primary Server 2.4)
byron.u.washington.edu (University of Washington Server)
hayes.fai.alaska.edu (University of Alaska Fairbanks)
cpac.washington.edu ([bailey.cpac.washington.edu] UW IRC Server V2.2PL1)
unicorn.wwu.edu (WWU Fantasy Server)
hammer.me.utoronto.ca (UofToronto Server)
galaxy.ee.rochester.edu (Univ of Rochester, Department of Electrical Engine)
sirius.ctr.columbia.edu ([128.59.64.60] Columbia University CTR, New York C)
NeXT210.NOdak.edu (You Can't Find It In the Atlas)
ronin.us.cc.umich.edu (U. of Michigan ITD Consulting IRC Server)
srvr1.engin.umich.edu (University of Michigan, CAEN IRC Server, Ann Arbor)
oak2.math.ucla.edu (UCLA Mathter and Servant)
astemgw.astem.or.jp (ASTEM Research Institute, Kyoto, JAPAN)
cnam.cnam.fr (Centre National des Arts et Metiers v2.2PL, Paris,)
monu6.cc.monash.edu.au ([130.194.32.106] Monash University, Australia)
MED.STANFORD.EDU (Stanford Medical School Information Systems Group)
hercules.csl.sri.com (SRI Computer Science Lab, Menlo Park, CA  USA)
ucscb.UCSC.EDU (University of California at Santa Cruz, IRC 2.4)
lucid.com (Menlo Park, California, USA)
utsun.s.u-tokyo.ac.jp ([133.11.7.250] University of Tokyo, Japan <2.4>)
choshi.kaba.or.jp ([choshi] Kyoto Artificial Brain Associates, Kyoto,)
kimura4.kuee.kyoto-u.ac.jp ([130.54.30.164] Kyoto University, Japan <2.4>)
jerry.tom.astem.or.jp ([133.18.192.1] Kyoto Junction Server, ASTEM, Kyoto)
eris.Berkeley.EDU (Berkeley Ultra-Hoopy Test Server)
betwixt.cs.caltech.edu ((Caltech Server) <irc2.4>)
ucselx.sdsu.edu (San Diego State University, CA   USA)
paris.ics.uci.edu (University of California, Irvine <2.4PL0>)
ccnext.ucsf.edu (UCSF IRC Server)
cssun1.cs.indiana.edu (Indiana University Test Server)
iucs.cs.indiana.edu (Indiana University Test Server)
silver.ucs.indiana.edu (Indiana University Test Server)
irc.andrew.cmu.edu ([FAIRHOPE.ANDREW.CMU.EDU] Generic Brand CMU IRC
spot.colorado.edu (University of Colorado, Boulder)
hamblin.byu.edu (BYU Math Dept)
cie.uoregon.edu (The Campus Information Exchange's IRC Server)
uhura.cc.rochester.edu (University of Rochester - Rochester, NY)
netserv2.its.rpi.edu (Rensselaer Polytechnic Institute, Troy NY)
sun.soe.clarkson.edu (Clarkson, Potsdam, NY 13676)
--
--russ ([email protected] [.bitnet | .clarkson.edu])  [email protected]$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 19:25:45 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!brut[email protected]ucsd.edu
To:        [email protected]
Subject:   Trivial Ethernet Analyzer software available
Here is something that I have wanted for a long time, but never found.
Finally I got so fed up, I wrote it myself.  Here is an abridged version
of the software discription document.  

At present, it is unavailable via E-mail.  But if someone places it
on a E-mail archive site and lets me know, I will pass that information
on to interested parties.   If this is a MAJOR problem for you, let me
know, and if there is sufficient interest, I will post the software to 
comp.binaries.ibm.pc.  

Vance

--------------------------------------------------------------------------

                    A Trivial Ethernet Analyzer
                           Vance Morrison


    Very often a network administrator has to debug networking problems
given only the raw symptoms of the problem (my program hangs).  Trying
to debug given such sparse information is difficult at best and impossible
at worst.  Often the ability to 'snoop' on the network and watch the 
packet dialog is VERY helpful.  Basically I have written a program
called 'analyzer' that watches packets go by on the network and prints
them out in a human readable form.   At present, this program only 
understands TCP/IP protocols (and not all of them), and for security
reasons analyzer only prints what it understands.  Thus at least at
present, analyzer will not help with DECNET, XNS, ETHERTALK traffic.

WHAT YOU NEED

    In addition to the analyzer.exe executable (available from 
accuvax.nwu.edu (129.105.49.1) in pub/pcroute/analyzer), you will also 
need a PC with a network card, as well as the clarkson packet driver for 
that  card.  The clarkson packet driver is a piece of software that allows
analyzer.exe (as well as other programs) to access the network card in
a device independent way.  A driver exists for most of the common networking
cards, and is available (among other places)  sun.soe.clarkson.edu 
(128.153.12.3) in the directory 'pub/packet-drivers'.  Note that some
packet drivers do not support 'promiscuous' mode (in particular I know the
ni5010 does not).  In that case analyzer.exe will work, but will not be
of much use (since it will only see packets destined for the itself and
the broadcast address).  I do know that the wd8003e driver DOES work.

SHORTCOMINGS

Admittedly, analyzer is not a very flexible program.  The philosophy here
is that something is a LOT better than nothing, and once you have the
output as ASCII output it can be filtered and beautified to your hearts
content.  For example, if you have a batch editor (like sed), you can
do a global search an substitute to replace ethernet addresses with a
more mnemonic one.   Also, I did NOT what to spend a lot of time on this,
analyzer in its present form is about 3 days work.

SECURITY ISSUES

In an ideal network, it shouldn't matter that a program like analyzer
exists.  However, life is not ideal, and passwords and other sensitive
data are routinely sent in unencrypted form across nets.    I have therefore
gone to a little trouble to make analyzer 'safe'.  It only prints out
parts of packets that should not contain sensitive data.   While this is
not foolproof, I believe is does open any security loophole any wider
than it already is (which is actually pretty wide).  

EXTENSIONS

Usually I provide the source code to my work so that if anyone wants
to make extensions they can do it themselves (and not bother me).  In
the case of analyzer, this would be particularly nice since analyzer
does not print (in any form) what it does not know, and analyzer is
a pretty ignorant program (:-).  Unfortunately releasing source would
be a security problem, since it would be VERY easy to modify analyzer
to do mischief.  Thus I propose a compromise.  If analyzer does not
print output packets that you want to see, simply write some C code
that takes a pointer to that packet and prints it out.  I have included
the file 'ip.c' in the distribution to give you an example of how to
do it.  If you send this file to me, I will look it over for security
holes, compile it, and send you an executable.  This arrangement is
less than perfect, but it will give you an option if you wish to exercise
it.

COPYRIGHT

Please notice the copyright.  This is shareware.  You are allowed to
use this software on a trial basis for one month.  If after that time
you find analyzer and wish to keep using it, send a $10 registration
fee to the address below.    See the analyzer.doc file for details.
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 19:48:59 GMT
From:      [email protected] (John G. De Armond)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.nfs
Subject:   Dialup x.25 & nfs questions

I have a couple of questions regarding the use of tcp/ip over x25 in
a dialup environment.

The environment is:

IBM RS/6000 320, Uninet SLAT, v.32 modems on one end and 

IBM 3081 with 3745 on the other.

Questions:

	Does anyone have any experience with a setup similiar to this?

	How does x.25 in a point-to-point environment compare to SLIP?

	How does x.25 and v.32 compare in performance to {slip,x.25,
	other protocols} and trailblazers?  Particularly in noisy environments.

	Any other general comments?


Second question.

From this same RS/6000, there is a need to connect a PC over ethernet.
PC-NFS has been proposed.  I have little experience with NFS in general
and no experience with PC-NFS in particular.  This connection will involve
an unmanned PC and therefore must be reliable.  Any comments positive
or negative would be appreciated.

I have to discuss these situations in the next few days so any comments
would be greatly appreciated.  E-mail prefered.

Thanks,
John

-- 
John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**  

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jun 90 01:01:50 EST
From:      [email protected] (Martin L. Schoffstall)
To:        [email protected]
Cc:        [email protected]
Subject:   migrate.to.iso, off we go......
> 
> I don't quite agree with it. As I've explained, since the U.S. Government is
> getting poorer, they can not afford to replace the "old" technology. Moreover,
> they don't want have an error especially under tactical environments. That's
> why TCP/IP technology is now getting matured. But I don't think it is "best"
> technology. I would call it "old" technology.  About 1983, I had a chance to
> design and implement DoD protocols with MIL STD for the U.S. Government.  
> I've found a whole bunch of errors on MIL STD specs. I wrote a letter to
> DCA about those errors. Still 1990, they are using the same MIL STD specs. 
> Do you know why ?? Because they don't have enough money to revise it. Actually,
> MIL STD were written by UNISYS under some contract. 

The US Government seem to be as rich as ever to me; however, don't confuse
the MILSPEC's of 1983 with the Internet and its technology of 1990.  A
lot has been done in the RFC series and in many other publications, more
importantly these improvements have been widely implemented, and the
rate of improvement of the TCP/IP technology is accelerating.
> 
> 
> 	If you are saying same words to Korea or Japan Government/Industries/
> Universities, they are going to laugh. About a year ago, when I had a chance
> to go back to Korea, I was invited from several institutions and Korea 
> Government Organizations which are dealing with the highest technologies in 
> the world. Not many people wanted to talk about TCP/IP. They were already
> migrated to OSI world. In these days, I am envolved with the projects with
> Euroupe. That's why I was interested in U.K. GOSIP. They are interested in
> U.S. "old" TCP/IP technology, but I don't think they will change their 
> existing systems for it.   

Dozens of commercial organizations laugh all the way to the
bank as they export tcp/ip products to the Pacific Basin to the who's who
of commercial enterprises.  I don't know what the "highest technologies in
the world" are, but I have been told that you need to be high to fully
appreciated OSI and GOSIP.

> 
> Some of your statements I agree. Evenif OSI technologies are still 
> premature, I don't see 10 years. It's slow sometimes, but the whole world 
> is rapidly moving into one OSI world.
>
With sufficient soma it is possible that some might believe that we're
rapidly moving into the brave new world of OSI.  Unfortunately the
monetary investment in product and services doesn't support that.

Philosophically what you need to consider is the concept of coexistence
which will exist 10 and 20 years from now.  Only a very small amount of
the market is going to migrate to OSI in the near term, undoubtedly
for good political reasons, not technological ones.  Considering that most
of the OSI technology will run over things like X.25, which is truelly
ancient technology, the ability to even prove the utility of the OSI
technology sometimes appears doomed.

You say your messages are serious, but I have to reread them to make sure
that BIFF or PVM isn't spoofing us all.

Marty

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 21:06:10 GMT
From:      [email protected]  (Kayvan Sylvan)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
>>>>> "brnstnd" == brnstnd <[email protected]> writes:

brnstnd> What's the solution? Mix 'n' match. A password has, say, two
brnstnd> parts: one chosen by the user and neither expired nor
brnstnd> restricted, one generated randomly by the system and changed
brnstnd> periodically (some sizable fraction of a year). The first
brnstnd> part is NEVER written down; users are told that if they write
brnstnd> down the first part, they'll be drawn and quartered. The
brnstnd> second part is almost certainly written down, typically on a
brnstnd> piece of paper in the user's desk; users are explicitly told
brnstnd> that this is okay.

Hmmm... Interesting. If the paper on which the second part is written
down is kept locked up (or otherwise is inaccesible to random
snooping), then it jut might work.

			---Kayvan
-- 
| Kayvan Sylvan @ Transact Software, Inc. -*-  Los Altos, CA (415) 961-6112 |
| Internet: [email protected]{mrspoc.Transact.com, eris.berkeley.edu, largo.ig.com}   |
| UUCP: ...!{apple,pyramid,bionet,mips}!mrspoc!kayvan "Imagine Cute Saying" |
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 21:32:11 GMT
From:      [email protected]  (Kraig Meyer)
To:        [email protected]
Subject:   Re:  Growing sentiment against gateways
In some article someone wrote:
||> (One could argue that those "gateways" violate the access rules for
||> the Internet, since they cannot verify that the message came from an
||> authorized user of the Internet.)
  
In article <[email protected]> [email protected] (der Mouse) writes:
||You mean there *are* access rules for the modern Internet?  This sounds
||suspiciously as though you're thinking of the DARPA rules, which (it
||seems to me) don't really apply, with the demise of the ARPAnet core.

Most, if not all, of the regional networks attached to the NSFnet backbone
have appropriate usage guidelines.  Traffic which is solely for commercial
purposes is prohibited from traversing the NSFNet backbone--there are most
definitely rules which govern Internet access.  However, in the case of
gatewaying the tcp-ip mailing list to and from usenet I think it could very
easily be argued that this fits appropriate usage guidelines.
---------------------------------------------------------------------------
| Kraig R. Meyer		   		    [email protected]  |
| University of Southern California                          Los Angeles  |
---------------------------------------------------------------------------
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 22:41:27 GMT
From:      [email protected] (Chad R. Larson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Print Spooler
In article <[email protected]> [email protected] (Deepak Munjal) writes:
+---------------
| Does anyone know of a box that will take TCP/IP based Unix spooled 
| printer output and convert it something an RS-232 printer can understand?
+---------------
    Microtest
    3519 East Shea Boulevard
    Suite 134
    Phoenix, Az 85028
    (800) 526-9675

They have a product called LANPORT which does exactly what you want,
but for a Novel network.  Call 'em anyway.  If enough people express
interest, they may make it.  They're a small company and after all,
"it's only software".  New ROMs should do it.
	-crl
-- 
Chad R. Larson          ...{mcdphx,asuvax}!anasaz!chad or [email protected]
Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020
(602) 870-3330            "I read the news today, oh boy!"  -- John Lennon

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 00:23:33 GMT
From:      [email protected] (Jeff Makey)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Shadow password files (was: anonymous ftp, and the dangers thereof)
In <[email protected]> [email protected] (Barry Shein) writes:
>The objection to shadow password files is that it's an admission that
>hiding the file contents is critical to the entire system's security

"Critical" is the wrong word, here.  The use of shadow password files
is nothing more than an application of the well-established concept of
"in-depth" security measures, where the security of the system does
not depend completely upon any single security feature.

>Don't argue that it merely "improves" the
>existant security, fine, you obviously decide for yourself so you can
>believe whatever you like. Multiplicative probabilities aren't
>compelling arguments.

Probability theory is just so much bunk, huh?  You can disbelieve
whatever you like, I guess.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: [email protected]    UUCP: {nosc,ucsd}!logicon.com!Makey

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 01:07:09 GMT
From:      [email protected] (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <[email protected]>, [email protected] (Steven M. Schultz) writes:
> 	just a "thought" - if the (shadow)file is non-world readable and the
> 	system is administered "correctly" then why bother with
> 	encryption at all ;-)

Go back and read the Morris/Thompson paper.  Basically, files can leak,
due to carelessness, bugs, hard-copy terminals, backup tapes, etc.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 03:44:16 GMT
From:      [email protected] (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, and the dangers thereof
> Some sites keep anonymous FTP directories to be world-writable,
> letting any random internet user drop a file in a directory.  If you
> see a file named GETMONEY.txt, makemoney.doc, or sex-bbs.doc (or
> variations on same) in your FTP directory, this is why.  It is not
> good practice to allow random anonymous users to scribble into
> directories ...

The obvious counter-example to this is /usr/spool/uucppublic, which
is almost always world-writable, yet there seem to be no reports of
even minor problems with this.  It's usually considered a useful
part of uucp, and an assortment of tools are around (uuto/uupick for
example) are layered on top of it.

It's true (in fact, it's obvious) that one could fill up a victim's
disk partition.  But this isn't doesn't seem to trigger call for 
shutdowns of all uucp sites until the horrible security problems 
are fixed.  (Well, OK, users of competing packages *do* make such
calls, but not uucp's users. ;-)

So why is it such a disaster if an anon-ftp directory is writable?

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 04:26:49 GMT
From:      [email protected] (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: trash message from usenet (BIFF)
In article <[email protected]>, [email protected] (Michael O'Dell) writes:
> The notion that mail or mailing lists on the Internet are either
> "secure" or "accountable" is simply hysterical.
> 	-Mike

Insults aside, I'd like to hear a coherent definition of these terms
with regards to mailing lists.  I'm not being facetious or asking a
rhetorical question.  It's clear that people have some concept in mind
when they use such phrases; I'd like to read a definition that can be
used to develop software.  It's all very well to say that you want your
system secure, verifiable, and all that.  But until you've said quite
precisely what these terms mean, you're speaking sales propoganda, 
not computer engineering.

The basic problem is that a mailing list is basically an automatic
forwarder.  All that I've seen work in the same way:  There is a 
pseudo-user (account) "mlist" on machine "foo", and any mail to
[email protected] (or foo!mlist or foo::mlist or ...) gets bounced to all
the recipients on a list.  Anyone who knows how to get mail to foo
can send a message to the entire list.  This isn't a bug; it's what
the list was meant for.  What would it mean for a list to be secure?

Would this perhaps mean that nobody not on the mailing list could
send mail to [email protected]?  This seems rather pointless.  After all,
the whole point of a mailing list is to encourage sending relevant
comments to everyone on the list.  If someone has a contribution
to make to a discussion, I'd certainly expect that I could show 
them what I'd received, and invite them to post their comments on 
the list by sending mail to foo::mlist.  Maybe they'd want to get
on the list, but that takes time; meanwhile they should be able
to contribute.

Does secure perhaps mean that the mail can't go to anyone not on
the list?  This seems a bit naive.  I can always write a program
that scans my mail for articles from a list of sources, and mails
a copy to someone else.  I can't imagine how the manager of the
mailing list could prevent my doing this.  For that matter, as
the manager of email on this machine, I could write a filter for
all incoming mail looking for certain subjects, sources, keywords,
etc., and do whatever I want with them.  Sure, some people will 
be outraged (or would, if they found out :-); others would insist 
that I am legally required to do so by recent court decisions...
But all that is beside the point; the point is that I or any other
email manager or recipient *could* do it, and the manager of the 
mailing list has no way whatsoever of knowing about it.

So when someone asks for a secure mailing list, what could they
possibly have in mind?  Is this just a vague, fuzzy buzz-phrase,
or does it have some specifiable meaning?

I might also refer y'all to John McCarthy's article "Networks
Considered Harmful for Electronic Mail" in last December's CACM,
for an interesting alternate opinion.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 06:07:00 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <[email protected]> [email protected] (Steven M. Schultz) writes:
>just a "thought" - if the (shadow)file is non-world readable and the
>system is administered "correctly" then why bother with
>encryption at all ;-)

I'm not sure how non-serious that smiley represents.  The serious answer is
that even system administrators should not be able to find out a user's
password.  Sure, they don't need to know the user's password to violate the
user's files.  But if they know someone's password then they could
accidentally (or through coercion) divulge it to someone else.

Also, two levels of protection are better than one: if the file is
accidentally made readable it is still encrypted.
						
--
Barry Margolin, Thinking Machines Corp.

[email protected]
{uunet,harvard}!think!barmar

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jun 90 20:39:00 -0700
From:      Marshall Rose <[email protected]>
To:        [email protected] (Michael McFarland)
Cc:        [email protected]
Subject:   Re: CMOT and MIB
RFCs 1155, 1156, and 1157 are "full standard protocols, with recommended
status"  according to the IAB.  They are, respectively, the SMI, MIB,
and SNMP.  Because 1155, 1156, and 1157 have reached the end of the
standardization process, the three documents together are sometimes
referred to as the Internet-standard network management framework.

RFC 1158 is a "proposed standard, with recommended status".  It is MIB-II, the
proposed successor to the Internet-standard MIB, and fully compatible
with RFC1156.

RFC 1095 is a "draft standard".  It is CMOT.  There is a new
internet-draft specifying a new version of CMOT.  As it is an
internet-draft, it has no standardization status.

RFC 1156 can be used with both SNMP(1157) and CMOT(1095).  RFC 1109 said
that the work on SNMP and CMOT could use different MIBs.  RFC 1158 can
be used with SNMP.  I am told there is a document which casts RFC 1158
into a form useable for CMOT.

It is my believe that this is the "truth, and whole truth, and nothing
but the truth" regarding the standardization status of these
technologies.  Beyond this, work continues, both in producing new
experimental MIBs (e.g., for FDDI), and in re-evaluating existing
technology.

/mtr
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 09:38:31 GMT
From:      [email protected]  (Jim Sanchez)
To:        [email protected]
Subject:   Re: TCP-IP Print Spooler
There is a product called lanpr from an outfit called nexus in Sweden
that sends print jobs to an ip address and port number.  The idea is
that a printer can be connected to a terminal server port.  The newest
version also works with printers attaced to pcs and also lets pcs use
the unix system printers.  Sounds like a good product but I only
played around with the earlier version.  They company is on the net at
[email protected] so you can "ring them up" if you like.

I have NO relationship with them except as a one-time user.
Good luck
-- 
Jim Sanchez          | [email protected] (PREFERRED)
                     | OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems   | OR uunet!mcsun!ub4b!syteke!jim 
Brussels  
-- 
Jim Sanchez          | [email protected] (PREFERRED)
                     | OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems   | OR uunet!mcsun!ub4b!syteke!jim 
Brussels  
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Fri 8 Jun 90 15:02:02-CDT
From:      Matt Jonson <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected]
Subject:   Re: I need help with subnetting
   Dan-

   First let me say a few things about your current problem and then talk
   about your future with respect to subnetting.  Chances are that the reason
   your sun isn't gatewaying is simply because your routes and your ifconfigs
   aren't set up right.

   Using your diagram, the suns behind the gateway must have (x being their
   host number):
	 route add 129.61.9.0 129.61.9.x 0
	 route add default 129.61.9.2 1
   That will insure that their packets get to the outside world.  However,
   the outside world won't know how to get to them unless each one of those
   machines (unless you use proxy arp) has:
	 route add 129.61.9.0 129.61.2.40 1

   Your gateway sun should have these commands performed somewhere during
   start-up:
	 route add 129.61.9.0 129.61.9.2 0
       * route add default 129.61.2.40 0
	 (I'll get back to the asterix later)
   That gateway sun should have a netmask of 255.255.255.0 on BOTH ethernet
   interfaces.  Welcome to subnetting.

   The preceding was written on the assumption that you have a class B
   network just kind of floating in space with no other gateways to anywhere.
   This will not work if there are any other gateways to other things
   on your ethernet.  If, for instance you have a gateway to milnet on this
   ethernet, you should configure it as the default route and the * route
   command from above becomes:
	 route add 129.61.0.0 129.61.2.40 0
	 route add default 129.61.x.y 1
	 route add othernet gateway 1
   At this point you will also need to add routes for every other different
   third octet address on your class B.  It's a pain -- your other option is
   to pick an arbitrary third octet to rehome everyone on or a higher subnet
   to mask off of.

   When this network grows, and gateways start appearing, this kind of
   addressing scheme will get extremely unwieldy.  You will have to do some
   subnetting to streamline things.  You should probably take a good look at
   where you see this net going in the future and think about who will and
   who will not be needing the capabilities of subnets.  Right now you really
   only have a class B ethernet, and except for this one hitch, that is still
   what you have.  If you don't subnet, you will have to make sure that every
   host on the net has a route to every other important gateway.
   But of course there's always proxy arp...

   You should probably try to migrate toward this kind of subnetting:

			     129.61.A.*
     host|net B --  129.61 __________________
	 |-----|GW|--------|   Subnet A     |                  +---SUN
     host|      --   A.a   |   main net     | 129.61 |---|129.61
			   |                |--------|SUN|-----| net C
			   |                |  A.x   |---| C.y |
	 |net D --  129.61 |                |                  +---SUN
	 |-----|GW|--------|                |
	 |      --   A.b   +----------------+

   In this scheme, your gateways will be the only things that have to know
   how to reach the other nets.  Your hosts will just have to know who their
   gateway is.  It is clearly superior to having to update everyones tables
   every time there is a change in the future.

   I noticed you were an Air Force user, so I figured we should get back to
   you.  We'd be happy to help you out with your (potential) subnetting
   problems.  That's one of our functions as the AF DDN PMO.  Please get back
   to us with the details of your net (who connected to, gateways, third
   octet numbers assigned...)

   Right now you are actually subnetting with all 8 bits of the third octet.
   That gives you 254 potential subnets.  You may only need to use the first
   three, four or five bits which will give you 8, 16 or 32 nets...

   POCs are Lt Matt Jonson, Darrel Beach, Capt Brad Wright.  AV: 446-4075


   Matt Jonson
   Network Systems Engineer
   [email protected]
   (205) 279-4075





-------
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 13:38:50 GMT
From:      [email protected]  (toshihiko.yamakami)
To:        [email protected]
Subject:   Re: A proposal on "comp.protocols.migrate.to.iso"
From article <[email protected]>, by [email protected] (Russ Nelson):
> In article <[email protected]> [email protected] (Kwang Sung) writes:
> 
>    	If you are saying same words to Korea or Japan Government/Industries/
>    Universities, they are going to laugh.

I believe Japanese industries will not laugh.
 
> I just went into 'irc' (Interactive Relay Chat), and did a '/links' command.
> The hosts that are linked into irc are listed below.  Not only is Europe
> well represented, so is Japan.  Perhaps you're right about OSI, but when
> people want to internetwork today, they get on the Internet.

I agree with you.

I know Korean industries are growing rapidly, these days.
However, as far as Japan is concerned, our industries
are short of both of TCP/IP engineers and ISO engineers.
We need both.

'International standard' is a nice word, however, it is a long way
to beat industrial standards proven effective.

To be honest, I am just a user for TCP/IP, little knowledge about
its implemetation details.
However, I have some experiences with ISO application layers
as an employee of NTT, a Japan communication giant:
	MHS implementation and multi-vendor conformance,
	ISODE 5.0 experimental use,
	member of Japanese body of ISO JTC 1/SC 18/WG 4.

From my understandings, there are lots of things to be fixed in
ISO application layer.
Even with Application Layer Structure(ISO SC21) and
Distributed Office Application Model draft(ISO SC18),
application structeres are not so clear.
There are lots of conflicting issues in ISO and CCITT application
standardization activities.
Group communication is under discussion, however, not yet focused.

So Japanese industries cannot throw away Internet protocol suites
in next decade.
At least, I cannot imagine it.

-- yam
-- 
Toshihiko YAMAKAMI(NTT, Japan) Resident visitor in Bell Labs until Feb 1991
 Room 4G634, AT&T Bell Labs, Crawfords Corner Rd. Holmdel, NJ 07733-1988
 Tel:(201)949-5742	e-mail: [email protected] (was: [email protected])
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 13:46:20 GMT
From:      [email protected]  (Liudvikas Bukys)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (John Chambers) writes:
>> It is not good practice to allow random anonymous users to
>> scribble into directories ...
>
>The obvious counter-example to this is /usr/spool/uucppublic, which
>is almost always world-writable, yet there seem to be no reports of
>even minor problems with this.  It's usually considered a useful
>part of uucp, and an assortment of tools are around (uuto/uupick for
>example) are layered on top of it.
>
>It's true (in fact, it's obvious) that one could fill up a victim's
>disk partition.  But this isn't doesn't seem to trigger call for 
>shutdowns of all uucp sites until the horrible security problems 
>are fixed.  (Well, OK, users of competing packages *do* make such
>calls, but not uucp's users. ;-)

1.  Here's one "minor problem" report: I have heard that .rhosts
    files have been uucped into ~uucp.  Think about it.

2.  Most uucp connections are point-to-point, many (most?) sites
    have a distinct login for each neighbor, and pretty thorough
    logging is done.  Under these circumstances, it is easy to trace
    a culprit back to a specific neighbor machine, and there is
    something you can do about it if no appropriate response is
    heard -- sever your connection to that neighbor.
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 14:00:15 GMT
From:      [email protected]  (Joe Schmo)
To:        [email protected]
Subject:   Duplicate Internet address on same network
I have two machines on my network using the same Internet address, and without
network analysis tools, I am having trouble identifying the culprit.  Could
somebody please tell me which manufacturer uses the Ethernet address
AA:0:4:X:X:X.


Thanks alot...

Reply to:
Steve Lodin
lodin%[email protected] or [email protected]
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 16:46:12 GMT
From:      [email protected]  (Bob Sutterfield)
To:        [email protected]
Subject:   Re: trash message from usenet (BIFF)
In article <[email protected]> [email protected] (John Chambers) writes:
   In article <[email protected]>, [email protected] (Michael O'Dell) writes:
      The notion that mail or mailing lists on the Internet are either
      "secure" or "accountable" is simply hysterical.

   What would it mean for a list to be secure?

   Would this perhaps mean that nobody not on the mailing list could
   send mail to [email protected]?  If someone has a contribution to make to a
   discussion... they should be able to contribute.

Some mailing lists have implemented filters to block users who
consistently and persistently post inflammable messages with the
particular purpose of inciting wars.  These mailing lists tend to be
ones carrying political or religious discussions and other topics that
are prone to particular emotionalism.  I don't know of any
technically-oriented list that has needed to take this step.

   Does secure perhaps mean that the mail can't go to anyone not on
   the list? ... I can always ... mail a copy to someone else.  I
   can't imagine how the manager of the mailing list could prevent my
   doing this.

This is the practice on certain security-oriented mailing lists, where
the list maintainer requests that members not forward the messages to
anyone not on the list, and not keep them in publicly-readable places.
The list maintainer enforces this policy by threatening to remove any
member from the list, upon sufficient proof of misbehavior.

   So when someone asks for a secure mailing list, what could they
   possibly have in mind?  Is this just a vague, fuzzy buzz-phrase, or
   does it have some specifiable meaning?

When I hear "secure mail" I generally think that it means that the
mail comes from the person named in the From: line, and goes only to
the person named in the To: line.  If the From: line is inaccurate
it's either a bug or a forgery, and if someone other than those listed
in the To: line reads the mail, it's either a bug or snooping.  I
think similar things about mailing lists, but in a one-to-many
context.

There are plenty of research projects in secure communications.  One
area is secure electronic mail.  But the S in SMTP is Simple, not
Secure.  Don't get your hopes up with something so Simple.
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 16:48:34 GMT
From:      [email protected] (Mark A Allyn)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   tcp for VMS and tcp over fiber-optics
I have an application where I have a VAX running VMS in a data center 
in one building and an office with a Macintosh running Appletalk along
with a Postscript printer in another building. Company security requires
that the only means of communications between the two locations is fiber
optics.

In the future, we may want to install a Sun or other Unix/tcp/nfs type
goody in the same room as the Macintosh and the printer. What I need help is
with the following.

The VAX has VMS and DECNET. Because we may have future Unix/tcp type 
stuff in our environment, we would like to have all communication via TCP.
I need some suggestions on what software to get for the VAX so that it can 
run TCP and preferably also NFS. I would also like something that includes
the necessary libraries and include files so that I can write applications
using sockets for both stream stuff and datagrams. I have heard of some names
including Wollengrad (sp?) but don't know anything about them. I need 
company names and phone numbers.

I need something that provides an ethernet bridge through a fiber optic. The
VAX has Ethernet which I hope to use for the TCP as well as the DECNET. I
also hope to get Ethernet for the room with the Macintosh and the future
Sun workstation. The two Ethernets need to be able to talk to each other 
through the fiber optic cable.

The Macintosh uses Appletalk which has its own set of protocols and hardware.
I need something to act as a gateway between Appletalk and the Ethernet with
TCP. I would like to provide the Macintosh with its own IP address and have
it appear as any other IP machine on the network. 

Since the Macintosh cannot act as a server since it is a single process
machine, I need something to act as a TCP server for the printer. The printer
should have its own IP address; that way, I can access it from any machine
on the network. Any Suggestions?

Can anyone please shed some light on any of this? I appreciate any company
names, books on this subject, or if possible to talk with someone who has
done this type of stuff in the past. I can be reached at:
(206) 773-8981 (206) 773-2957 (206) 773-8308 - days
(206) 526-8852 - evenings (til 9 pm Pacific time)

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 17:53:25 GMT
From:      sgi!rpw3%[email protected]  (Rob Warnock)
To:        [email protected]
Subject:   XTP multicast (was: VMTP)
In article <[email protected]>
[email protected] writes:
+---------------
| I'm designing a network in which a host running UNIX System 5 and
| using TCP-IP over Ethernet sends the same message to 16
| workstations.  Rather than send the same message 16 times, would
| like to broadcast the message to the workstations only once.
| Can't use UDP because the workstations have to acknowledge
| receipt of the update.  Do you know if there are any flavors of
| VMTP that will do what I need?  
+---------------

Don't know about VMTP, but the reliable multicast mode in XTP does
exactly that. Depending on how you twiddle the policy knobs, the
mechanism supports the range of multicast from "fire-n-forget"
datagrams (NOERROR) at one end of the spectrum, through "mostly"
reliable datagrams and streams ("mostly" here means "as good as
you want" depending on how many retransmission buffers are kept)
in the middle to "completely reliable" (positive acknowledgement
from each host that the data has been delivered all the way up
to the user process) datagrams and streams at the other end.

The "mostly reliable" mode can offer an arbitrarily low error
rate without requiring a reliable (or indeed *any*) group
membership protocol. The "completely reliable" mode does
require an external method of determining group membership.

Code for XTP is still under development, and is shared on an ongoing
basis with XTP Technical Advisory Board (TAB) members and Research
Affiliates (RA's). The most recent release [March 1990] of the
Unix-based XTP Kernel(-resident) Reference Model (KRM) included an
implementation of the "mostly reliable" multicast mode. For more
information about participating, or for a current "press kit",
please write/call/email/fax:

	Larry Green, President		Phone: (805)965-0825
	Protocol Engines, Inc.		FAX:   (805)687-2984
	1900 State Street, Suite D	Email:	[email protected]
	Santa Barbara, CA  93101	   or	[email protected]

The press kit includes the XTP Protocol Specification, Revision 3.4
(17 July 1989), but be sure to ask for it explicitly anyway.


-Rob

-----
Rob Warnock, MS-9U/510		[email protected]		[email protected]
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jun 90 22:09:21 EDT
From:      [email protected] (Louis A. Mamakos)
To:        [email protected], [email protected]
Cc:        
Subject:   Re: Mourning of the passing of the ARPANET
Milo,

If I'm not mistaken, the last production PSN on the ARPANET is/was PSN #17
at the University of Maryland.  It was but a shell of a network before its
time had come.. the only connection being an IST to the Princeton PSN, with
no host ports still in use.  A network with no user ports.

I had the honor/pleasure of turning off the power switch myself just a few
days ago..

louie


>Folks, it appears that the ARPANET has quietly passed away into the annals
>of network history.  June 1 was the official cut off date I believe, and I
>did some traceroute's to a net 10 host and not even the DDN Core knew
>about a route to net 10!  Not even the Mailbridge at BBN in Cambridge.
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 20:21:39 GMT
From:      [email protected]ucsd.edu  (Asad Shaikh)
To:        [email protected]
Subject:   Floation Point problem
I am using Phil Karan KA9Q code for my distributed system.But I am unable
to work with floating point numbers.Even I enabled float in makefile.
When ever I try to print statement like this
printf("%f\n",a);
I get divide error.
If some one has used this code for float please send me message.
Thanks
ASAD SHAIKH
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 20:38:02 GMT
From:      [email protected]iana.edu  (Michael McFarland)
To:        [email protected]
Subject:   CMOT and MIB
Can someone tell me where I can get the
latest status of CMOT? I have RFC 1095.

Also the MIB? I have RFC 1066.

Are there two MIBs now? One for SNMP, one for CMOT?

Has either RFC been superseded? 

I keep hearing these rumors...


Thanks, 
	Spike
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 20:52:27 GMT
From:      [email protected]  (MCV Subramaniam)
To:        [email protected]
Subject:   Re: SLIP source wanted for HP9000/340
>In article <[email protected]> [email protected] (Reiner Petersen) writes:
>>In article <[email protected]> [email protected] (Marcel Bernards) writes:
>>[] Hello NetReaders,
>>[] I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5/7.0.
>>We are interested too.
>>
>>-- reiner
>
>Well, this makes about 50 requests over the last year or so in this forum,
>with absolutely no response from hp. The response is no better from
>sales reps :-). Is there any hope that slip or cslip will be available
>sometime in the near future, or should I just give up and buy a couple
>or Sun machines? This is important! Please let us know.
>
	We are working on SLIP for the HP-UX 8.0 release. Please contact
	your local HP representative if you need more information.

-Subbu
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 00:55:02 GMT
From:      [email protected]  (Karl Auerbach)
To:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
In article <[email protected]> [email protected] (Amanda Walker) writes:
>The restricted variant of ASN.1
>that is used in SNMP can actually be pretty quick to parse.  Most of the
>publically available ASN.1 parsers that I have seen are overly complex...

"pretty quick to parse" is a relative term.  I've optimized my ASN.1
tools to handle the SNMP subset and they are fairly efficient, on a
relative scale.

The trouble is that even the limited subset of ASN.1 used by SNMP
represents a fair computational load.  Optimizing it and saying that
the result is good is a lot like saying that you have optimized a
bubble sort -- no matter how well optimized, it is bad news when presented
with anything more than trivial input.

The argument that one can optimize ASN.1 is a red herring.  The
trouble is that ASN.1 requires that one look at a significant number
of bytes, no matter how well optimized.

For things where one has a fairly fixed structure (SNMP being a prime
example) the flexibility of ASN.1 isn't warranted.  As a general
representational tool ASN.1 is OK (not great, but OK).  But for things
that happen often and where the content is fairly predictable (in
structure), a less universal tool ought to be considered.

I'm into my fourth ASN.1 BER encoder/decoder tool.  It does everything
in the ASN.1 BER specification (except floating point) and obeys all
kinds of constructorization/definite-indefinite length strategies and
I have not yet found an input sequence that breaks it (although
massivly deep constructors can cause it to reject an otherwise
legitimate input sequence.)  It was designed to be moved to hardware
as a co-processor.  I'm still profiling and optimizing the code paths
to do fastpathing, bulk operations and pattern matches when possible.
It is small (less than 20K bytes of compiled code on an Intel *86
processor) and, for ASN.1, fast.

My ASN.1 encoder/decoder for SNMP is far smaller, about 3K bytes of
compiled code on an Intel *86 class machine.  And considerably faster.
But even with this efficient code (at least I think it is efficient) I
find that ASN.1 parsing/encoding burns a significant portion of the
overall CPU cycles required to handle an SNMP request.

The potential flexibility of ASN.1 just isn't worth the expense in
situations (like SNMP) where we don't need the flexibility.

We of the internet community ought not to fall into the OSI trap of
thinking that just because ASN.1 exists that it is the perfect tool.*

				--karl--

*I used to own an English sports car (Jensen Healy) and I carried a
set of calibrated hammers.  Each was tuned to correctly bash whatever
thing wasn't working at the time.  A tiny hammer for the carburators,
a mallet for the fuel pump, and a sledge for the front suspension.  To
me, the use of ASN.1 for SNMP is akin to using the sledge to adjust
the carburator.
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 11:48:28 HST
From:      Torben Nielsen <[email protected]>
To:        sw[email protected]ucsd.edu, [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
These statements about the glorious OSI environment in Korea sound pretty
silly. KAIST has just established a 56Kbps link to the Internet. And
they at least claim to be building a larger IP network. Also, I just finished
installing the *fourth* 64Kbps link to Tokyo. All of them running IP.

No doubt there's interest in OSI migration in both Japan and Korea. But - and
this is my personal impression - neither is much further along that path than
we are. Unless you count their greater reliance on X.25 and take that as
a plus.....

Australia and New Zealand have extensive IP networks too. They're simply
being pragmatic. Actually, the Australian network (AARN) is about the
most impressive accomplishment in IP network construction I can think of.
They connected just about all the universities in the country in one fell
swoop; the whole thing was planned and executed very nicely.

							Torben


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 14:22:51 HST
From:      Torben Nielsen <[email protected]>
To:        [email protected], [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In response to Kwang Sung's message, Amanda Walker states:

>In article <[email protected]>, [email protected] (Kwang Sung) writes:
>> If you are saying same words to Korea or Japan Government/Industries/
>> Universities, they are going to laugh.
>
>They haven't so far.  TCP/IP is used by many Japanese universities and
>industry leaders for the reason that it works and is available right now.
>They may be doing research into OSI and MAP/TOP, but they still use TCP/IP
>to get their work done.

The key point here is what the governments are saying versus what the users
are actually doing. Certain government groups may be favoring OSI and pouring
lots of money into ``OSI networks".  But most all of the actual users I
know of are busily putting together IP networks. Even if they have to raise
the funds from non-government sources as often happens. For the users - largely
scientists, R&D people and students - the key is communicating with their
counterparts elsewhere. Currently the Internet is the best vehicle for doing
so. The great majority of users simply don't give a damn what the protocols
are. They merely wish to get the job done as easily and conveniently as 
possible.

There's a *lot* of work to be done to make *any* kind of network support
actual user needs. It would sure be nice if we could spend more time on that
instead of on silly religious wars.

Kwang Sung: from what I've seen, Korea has a long ways to go before they
have any kind of national network supporting the whole research community.
So does Japan. And so does the US for that matter. If you're interested in
how to do national networking *efficiently* (in terms of reaching your
audience and making it possible for them to do what they need to do), take
a look at the Australian AARN. It's very well done.


						Torben
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jun 90 16:40:16 -0700
From:      Marshall Rose <[email protected]>
To:        [email protected] (Karl Auerbach)
Cc:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
Karl - we've reached a circular discussion here.  The SNMP PDUs were
written in ASN.1 so as to be as fixed and predictable as possible.  That
is one method that was used in order to help out people optimizing their
encoders and decoders.

I suppose the PDUs could have been written in such a way as to use more
of ASN.1's expressive-ness, but the only benefit would be to be more
elegant in an academic fashion with no gain in functionality.  Of
course, the drawback would be that it would be nigh impossible to do
optimizations.

Sure, SNMP could have used a special-purpose, roll your own encoding
algorithm.  And sure, it could be faster than any form of ASN.1 known to
man; probably an order of magnitude faster, if you were very, very lucky.

And what would that cost exactly?  Well, let's see, it would be yet
another special-purpose thing useable only for one task; it would have
associated with it the usual debugging cost for the designers; it would
also have the usual start-up and training costs for the people writing
implementations.  So it would have a lot of hidden costs that would slow
development and hinder deployment.  (And to add insult to injury it
would still need to have things like ASN.1 object identifiers to provide for
decent naming and extensibility.)

Now I hate to be the one to point this out, but technological issues are
hardly boolean.  Any time someone says "X is better than Y", they have
neglected to state the criteria associated with that judgement.  As
such, there is more to consider than just raw speed when discussing this
issue. 

/mtr
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 09:06:46 EDT
From:      Hans-Werner Braun <[email protected]>
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
Milo:

There is no need to be mourning. (D)ARPA did a great service to the networking
community over the last many years in developing and providing a research
facility that emerged into operational infrastructure. Many spinoffs were
created, both in the government (including your NASA Science Network) as
well as other places, including internationally. As we all know, DARPA is
still continuing to do network research, that should yield further results
and benefits to the networking community. There have never been more users
and equipment using technology developed for the ARPANET than there are today.
The ideas, the spirit and the technological thrust of the ARPANET is surviving
in its children. At DARPA and elsewhere.

	-- Hans-Werner
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 12:38:31 PDT
From:      [email protected] (Kwang Sung)
To:        [email protected], [email protected]
Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward one OSI world !!,
even if ISODE has screwed up OSI world a little bit. 

	Moreover, a lot of people were also interested in the network 
technology in Korea. I would like explain later as much as I know about it. 
I am sure those informations should be much more updated now than a year ago.
Those informations were based on the systems/networks on KAIST, KIST/SERI, 
ETRI, RIST, Korea Defense Department, DACOM, SNU, and several industries
in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ [email protected]       \ 72265,23 (CompuServe)
>Systems Engineer \ [email protected] (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #[email protected] (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>

>Consider this a vote for the newsgroup. There's an effort in the IETF and
>ANSI to provide dual IS-IS routing for both IP and OSI. Ross Callon is
>the chairman; you can reach him at [email protected]

--------------------------------------------------------------------------------


Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward OSI world !! 

	A lot of people were also interested in the network technology 
in Korea. I would like explain later as much as I know about it. 
I am sure those informations are now much more updated than a year ago.
Those informations were based on the systems/networks on KAIST, ETRI, RIST, 
Korea Defense Department, DACOM, SNU, and several industries in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ [email protected]       \ 72265,23 (CompuServe)
>Systems Engineer \ [email protected] (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #[email protected] (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: [email protected] (David Grieve)
>Organization: Corporation for Open Systems, McLean, VA

>I would call it "comp.tcp.osi.transition"

>Migration means you go away and then come back.  Transition means
>you go away for good.

>[email protected] OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!grieve
>DISCLAIMER:  Opinions expressed are not necessarily those of the
>Corporation for Open Systems, its members, or any standards body. 

--------------------------------------------------------------------------------

>From: nsc!asylum.sf.ca.us!karl (Karl Auerbach)

>	I propose a comp.protocols.migrates.back.to.tcp group to
>handle the situation when folks find out that ASN.1 eats all the cpu
>cycles and that the word "open" in OSI is something akin to the "open"
>invitation that a snake makes to a mouse when the snake opens its
>mouth.

I think this one was one of the junk mails. But it's funny !!

-------------------------------------------------------------------------------


	Next, I would like to introduce some networking activities in Korea.
Obviously, these informations must be updated now. However, this is what I
know about. One of their networks, KREONet is the National Computer Network
to provide networking services for the whole Korea R&D community. It is 
developed, managed and operated by KIST/SERI. Initially, they used TCP/IP, X.25,
SNA as interim protocols. However, they were migrated to OSI thru ISODE-POSIX,
Dual Protocol Hosts, TS-Bridge, and Application Gateways.

	They are interconnecting 8 cities as 9.6 Kbps and 56 Kbps leased line.
Especially, they set up T1 (1.544 Mbps) leased line between Seoul and Daeduck
Science town. They were using dialup lines or X.25 calls by using PSDN
(DACOMNET). 

	KREONet includes over 100 host machines such as CRAY-2S, IBM, CYBER,
VAX, SUN, etc.  They are using SDN gateway services that provide connection of
CSNET, UUNET, Internet, BITNET, etc. KAIST's IP Address is "sorak.kaist.ac.kr  
137.68.1.1".  In Daeduck science town, they are building FDDI MAN (100 Mbps). 

	They had all kinds of UNIX non-STREAM/STREAM products. They are using
Informix product as their national database solution.

	If I introduce one of their own systems, I might be able to tell one
system called "TICOM". It has 20 CPUs. One board has a couple of MC 68030.
They are using their own system bus (100 MB/s, 64 bits data, 32 bits address,
21 slots), 512 MB Memory, Multi I/O. They are using OSI protocols from OSIAM_C.
It has "pure" OSI stack, FTAM, X.400, X.500, VT, etc. It has STREAMS, TLI,
CLNP, TP4, SNDCP, and TCP/IP.  

	If you know more about OSI activities in Korea, please send an e-mail
to either "uunet!open.osia.re.kr!hwang" (OSIA Secretariat), or 
"[email protected]"

	By the way, they had SC21 meeting in Seoul in May, 1990. 
That's all, folks !!  I hope this helps. 

	Now, again, I would like to ask you whether we really need to vote
in order to create a new newsgroup either "comp.protocols.migrate.to.iso" or
"comp.protocols.transition.iso", or something like that. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: Those opinions were nothing to do with my employer.

I love OSI !!  I love OSI !!   Don't ask me why !!
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 10:06:40 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"[Part 1]
              							[Part 1]
Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward one OSI world !!,
even if ISODE has screwed up OSI world a little bit. 

	Moreover, a lot of people were also interested in the network 
technology in Korea. I would like explain later as much as I know about it. 
I am sure those informations should be much more updated now than a year ago.
Those informations were based on the systems/networks on KAIST, KIST/SERI, 
ETRI, RIST, Korea Defense Department, DACOM, SNU, and several industries
in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
you are discussing is so fresh and hot in my veins that I had to join in.

I recently returned from a symposium in Washington DC that explored the
transisition from TCP/IP to OSI.  The word is transition since migration means
travel to a certain place with intention to return.  There will be no intention
to return to TCP/IP once OSI is established.

Firstly, the people who ran and participated in the symposium can easily be
recognized as leaders in communication technology.
Dr. John McQuillan - consultant and free lance author of about 200 articles
	on data communication, designed and implemented parts of ARPANET.
Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
	textbooks, member of Natinal Academy of Engineering, Guggenheim and
	IEEE fellow, etc...
Dr Vintont Cerf - Vice President of the Corporation for National Research
	Initiatives, Chariman of Internet Activities Board, extensively
	involved with creation and growth of ARPANET.
Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
	of CS at U of Tenn.
Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
	networking technologies for the last 25 years.
Bill Johnson - VP of Networks and Communications at DEC.
Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
	development.
Bob Burnett - vp of Engineering for cisco.
John Hart - VP of Engineering for Vitalink.
etc...

All that follows come from the discussions at this symposium.

The major reason for a slower than expected transition to OSI is the installed
base.  TCP/IP is only a small part of the installed base with 1500 networks.
PC Lans total over 1 million networks, IBM SNA networks control hundreds of
thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
DEC has sold 3,000,000 ethernet ports to 61k customers.

The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
are practically the same (so much the same that people don't see a benifit
of using TP4 over TCP.)  Many of the TCP users will have the industry believe
that the Dod protocols having been used and tested over the past 20-30 years
is better than a set of protocols designed by open consensus.

For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
was never meant to support a network as large as the internet.  In fact,
at the rate of growth of TCP/IP, it will run out of address space within the
next 5-6 years.  SNMP is an example of hind-sight engineering, as is
sub-networks.  These are features designed into TCP after years of operation.
OSI has the advantage that it was able to use what was learned by TCP/IP people
to design the entire protocol set.

TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
for the high tech media.  OSI also has limitations here but has afforded
a modular stack to allow replacements of layers for progressive evolution.
TCP/IP will not support the upcomming applications such as multimedia as
well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
or take variously different routes (TCP/IP).

The major reason why TCP/IP is so prevalent in computer networks today is
not because it is technically superior than anything that was put out before.
But because it was given away as standard equipment on millions of
workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
If not for this fact alone, there probably would not be ANY country wide
interoperable protocol.

OSI is coming of its own.  GOSIP is US govt's requirement list for computer
procurements.  Initially specifying a small subset of OSI, it will evolve
to include the entire specifications.  No company will win a GOSIP bid
without OSI.  And the US Govt is will start using GOSIP to describe contracts
in August 1990.

DEC has commited itself to OSI.  All of its customers computer network nodes
are going to be converted to OSI with the release of DECnet Phase V.  I work
for DEC but not in communications engineering but please don't think this is a
plug.  DEC is the only company to be committed to converting its installed
base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
released in December (don't quote me, I am not speaking for DEC here).
With all DECnet as an OSI network, OSI will be on its way to being more
accepted.

Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
became a commercial success because research, standards and corporate
communities came together.  For OSI only standards community and more
the corporate community have endorsed it.  The research community is
behind TCP/IP for good reasons).

Corporations are developing transision strategies.
There are many way to transision to OSI from any protocol.  There are OSI
gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
are buying small OSI networks for experimentation only (this approach increases
expertise before the network becomes critical.)

TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
in Korea either.  The big reason here is that the PTTs that implement and
use the networks in Europe are connection oriented.  They wand Virtual
Circuits.  TCP/IP is a datagram network and is not acceptable.
Although there are TCP/IP node across the world, the North
American Continent is where it is most poular.  Europe, conerned about its 1992
common community has looked to OSI as common protocol since its inception.
Europe is poised to take advantage of OSI and will have nothing to do with
TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
protocols, not TCP/IP.

The future of internetworking is not simple.  The experts see TCP/IP
as an integral part of the worlds networking infrastructure.  But most will
agree that the core of the infrastructure must be based on a globally
accepted protocol, no matter how long it takes to implement. This is OSI.
DEC sees OSI as an enterprise wide backbone, with gateways for proietary
and early public networking protocols.
Basically, the world is saying that any and all protocols are going to be uses.
But the protocol itself is about important to most users as whether your car
has efi or carbeurator that is not a significant amount.  Users want
interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
with us for a long time (10-15-20-30 years).  The one that outlasts
the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ [email protected]       \ 72265,23 (CompuServe)
>Systems Engineer \ [email protected] (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #[email protected] (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>

>Consider this a vote for the newsgroup. There's an effort in the IETF and
>ANSI to provide dual IS-IS routing for both IP and OSI. Ross Callon is
>the chairman; you can reach him at [email protected]

--------------------------------------------------------------------------------


Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward OSI world !! 

	A lot of people were also interested in the network technology 
in Korea. I would like explain later as much as I know about it. 
I am sure those informations are now much more updated than a year ago.
Those informations were based on the systems/networks on KAIST, ETRI, RIST, 
Korea Defense Department, DACOM, SNU, and several industries in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ [email protected]       \ 72265,23 (CompuServe)
>Systems Engineer \ [email protected] (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #[email protected] (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: [email protected] (David Grieve)
>Organization: Corporation for Open Systems, McLean, VA

>I would call it "comp.tcp.osi.transition"

>Migration means you go away and then come back.  Transition means
>you go away for good.

>[email protected] OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!grieve
>DISCLAIMER:  Opinions expressed are not necessarily those of the
>Corporation for Open Systems, its members, or any standards body. 

--------------------------------------------------------------------------------

>From: nsc!asylum.sf.ca.us!karl (Karl Auerbach)

>	I propose a comp.protocols.migrates.back.to.tcp group to
>handle the situation when folks find out that ASN.1 eats all the cpu
>cycles and that the word "open" in OSI is something akin to the "open"
>invitation that a snake makes to a mouse when the snake opens its
>mouth.

I think this one was one of the junk mails. But it's funny !!

-------------------------------------------------------------------------------
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 17:08:30 PDT
From:      [email protected] (Kwang Sung)
To:        [email protected]
Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward one OSI world !!,
even if ISODE has screwed up OSI world a little bit. 

	Moreover, a lot of people were also interested in the network 
technology in Korea. I would like explain later as much as I know about it. 
I am sure those informations should be much more updated now than a year ago.
Those informations were based on the systems/networks on KAIST, KIST/SERI, 
ETRI, RIST, Korea Defense Department, DACOM, SNU, and several industries
in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.

--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ [email protected]       \ 72265,23 (CompuServe)
>Systems Engineer \ [email protected] (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #[email protected] (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: [email protected] (David Grieve)
>Organization: Corporation for Open Systems, McLean, VA

>I would call it "comp.tcp.osi.transition"

>Migration means you go away and then come back.  Transition means
>you go away for good.

>[email protected] OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!grieve
>DISCLAIMER:  Opinions expressed are not necessarily those of the
>Corporation for Open Systems, its members, or any standards body. 

--------------------------------------------------------------------------------

>From: nsc!asylum.sf.ca.us!karl (Karl Auerbach)

>	I propose a comp.protocols.migrates.back.to.tcp group to
>handle the situation when folks find out that ASN.1 eats all the cpu
>cycles and that the word "open" in OSI is something akin to the "open"
>invitation that a snake makes to a mouse when the snake opens its
>mouth.

I think this one was one of the junk mails. But it's funny !!

-------------------------------------------------------------------------------


	Next, I would like to introduce some networking activities in Korea.
Obviously, these informations must be updated now. However, this is what I
know about. One of their networks, KREONet is the National Computer Network
to provide networking services for the whole Korea R&D community. It is 
developed, managed and operated by KIST/SERI. Initially, they used TCP/IP, X.25,
SNA as interim protocols. However, they were migrated to OSI thru ISODE-POSIX,
Dual Protocol Hosts, TS-Bridge, and Application Gateways.

	They are interconnecting 8 cities as 9.6 Kbps and 56 Kbps leased line.
Especially, they set up T1 (1.544 Mbps) leased line between Seoul and Daeduck
Science town. They were using dialup lines or X.25 calls by using PSDN
(DACOMNET). 

	KREONet includes over 100 host machines such as CRAY-2S, IBM, CYBER,
VAX, SUN, etc.  They are using SDN gateway services that provide connection of
CSNET, UUNET, Internet, BITNET, etc. KAIST's IP Address is "sorak.kaist.ac.kr  
137.68.1.1".  In Daeduck science town, they are building FDDI MAN (100 Mbps). 

	They had all kinds of UNIX non-STREAM/STREAM products. They are using
Informix product as their national database solution.

	If I introduce one of their own systems, I might be able to tell one
system called "TICOM". It has 20 CPUs. One board has a couple of MC 68030.
They are using their own system bus (100 MB/s, 64 bits data, 32 bits address,
21 slots), 512 MB Memory, Multi I/O. They are using OSI protocols from OSIAM_C.
It has "pure" OSI stack, FTAM, X.400, X.500, VT, etc. It has STREAMS, TLI,
CLNP, TP4, SNDCP, and TCP/IP.  

	If you know more about OSI activities in Korea, please send an e-mail
to either "uunet!open.osia.re.kr!hwang" (OSIA Secretariat), or 
"[email protected]"

	By the way, they had SC21 meeting in Seoul in May, 1990. 
That's all, folks !!  I hope this helps. 

	Now, again, I would like to ask you whether we really need to vote
in order to create a new newsgroup either "comp.protocols.migrate.to.iso" or
"comp.protocols.transition.iso", or something like that. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: Those opinions were nothing to do with my employer.

I love OSI !!  I love OSI !!   Don't ask me why !!
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 10:11:24 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"[Part 2]
-------------------------------------------------------------------------------

								[Part 2]


	Next, I would like to introduce some networking activities in Korea.
Obviously, these informations must be updated now. However, this is what I
know about. One of their networks, KREONet is the National Computer Network
to provide networking services for the whole Korea R&D community. It is 
developed, managed and operated by KIST/SERI. Initially, they used TCP/IP, X.25,
SNA as interim protocols. However, they were migrated to OSI thru ISODE-POSIX,
Dual Protocol Hosts, TS-Bridge, and Application Gateways.

	They are interconnecting 8 cities as 9.6 Kbps and 56 Kbps leased line.
Especially, they set up T1 (1.544 Mbps) leased line between Seoul and Daeduck
Science town. They were using dialup lines or X.25 calls by using PSDN
(DACOMNET). 

	KREONet includes over 100 host machines such as CRAY-2S, IBM, CYBER,
VAX, SUN, etc.  They are using SDN gateway services that provide connection of
CSNET, UUNET, Internet, BITNET, etc. KAIST's IP Address is "sorak.kaist.ac.kr  
137.68.1.1".  In Daeduck science town, they are building FDDI MAN (100 Mbps). 

	They had all kinds of UNIX non-STREAM/STREAM products. They are using
Informix product as their national database solution.

	If I introduce one of their own systems, I might be able to tell one
system called "TICOM". It has 20 CPUs. One board has a couple of MC 68030.
They are using their own system bus (100 MB/s, 64 bits data, 32 bits address,
21 slots), 512 MB Memory, Multi I/O. They are using OSI protocols from OSIAM_C.
It has "pure" OSI stack, FTAM, X.400, X.500, VT, etc. It has STREAMS, TLI,
CLNP, TP4, SNDCP, and TCP/IP.  

	If you know more about OSI activities in Korea, please send an e-mail
to either "uunet!open.osia.re.kr!hwang" (OSIA Secretariat), or 
"[email protected]"

	By the way, they had SC21 meeting in Seoul in May, 1990. 
That's all, folks !!  I hope this helps. 

	Now, again, I would like to ask you whether we really need to vote
in order to create a new newsgroup either "comp.protocols.migrate.to.iso" or
"comp.protocols.transition.iso", or something like that. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: Those opinions were nothing to do with my employer.

I love OSI !!  I love OSI !!   Don't ask me why !!
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 20:44:41 HST
From:      Torben Nielsen <[email protected]>
To:        [email protected], [email protected]
Subject:   Quote
From Kwang Sung's diatribe....

>	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
>I've received so many responses. Among those, I've selected some best ones, 
>after I've thrown out some bad ones. 

Wouldn't do to let us read all of that garbage. ``No" votes truly are no good;
they should be discarded so we can have a fair poll here.....

Actually, I'm delighted you threw the following quote in there. Apparently
from someone inside DEC:

>>The major reason for a slower than expected transition to OSI is the installed
>>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>>DEC has sold 3,000,000 ethernet ports to 61k customers.

Can you say ``apples"? Now try ``oranges" and maybe ``pineapples".... Is this
the official DEC line explaining why the transition is going so slowly?

					Torben
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 21:01:00 HST
From:      Torben Nielsen <[email protected]>
To:        [email protected]
Subject:   Clarification......
In response to some of Mr. Sung's comments, I recently made the following
statement:

>Actually, the Australian network (AARN) is about the
>most impressive accomplishment in IP network construction I can think of.
>They connected just about all the universities in the country in one fell
>swoop; the whole thing was planned and executed very nicely.

Several people have pointed out that I'm not being nice to the NSFNet by 
saying such things :-) Well, I had no intention of saying that the
construction of NSFNet was somehow inferior.

However, irrespective of it's size, the AARN is a true national academic
network and they have more than just a few nodes on it. Moreover, it was
established with what appeared to be a minimum of fuss and bother. The primary
protocol is IP. Not because it's viewed as inherently better, but because
it's available and works *now*.

When we have a true national network that reaches all universities in the
country, I'll revise my statement. Waiting for the NREN :-)

As an aside, it's truly interesting to watch how national networks are
built/develop/grow. So far, I can see at least three major types of
scenarios.... No doubt ther're a lot more.

						Torben
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jun 90 17:55:20 -0400
From:      "Martin Lee Schoffstall" <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
 > In my SNMP code, my profilers indicate that an
 > overly large portion of the of cycles are spent in the ASN.1
 > encoder/decoder.  Maybe my code is inefficient -- although I doubt it.

Refresh my memory but doesn't your code base derive from an effort
to span the perceived market for both CMOT and SNMP?  Could this
be a factor?  I've seen some very tight code by commercial implementors
of SNMP.

While you make the comparison of ASN.1 vs "SNMP" within your
code base, do remember that the tradeoff were made between

	doing real work code (such as routing)
		vs
	network management code

inside the network entity.  That was the foundation of all
critical engineering decision tradeoffs.

Your statement above leads me to believe that you aren't seeing the forest
for the trees.

Marty
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 16:00:50 GMT
From:      [email protected]  (Brian Kantor)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
A few of us are sorta planning to hold a wake for the Arpanet at Usenix
next week.  We just haven't found the proper bar yet.
	- Brian
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 18:28:09 GMT
From:      [email protected]  (John Chambers)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]>, [email protected] (Warner Losh) writes:
> 
> In article <[email protected]>
> [email protected] (Mark Crispin) writes:
> >... There are lessons to be learned, starting with the
> >abolishment of /etc/passwd and user access to the encryption
> >algorithm.
> 
> Sorry.  There are too may passwd files out there to do this.  Shadow
> files might help, but then again they might not.  

Logistics isn't the only problem; an unreadable password file can
decrease security in some situations.

I've written several packages that, when talking across a comm line
that needs extra security, will occasionally say, in effect, "I'm
not sure you are who you claim to be; please type your password: "
On a system with an unreadable encrypted password, the application
(which isn't running as super-user) is denied read access and can't
check the password for validity.  So when the software is ported to
such systems, this checking normally just gets #ifdeffed out (so we
can get the application delivered on time ;-).

Now it's true that there are other solutions possible.  But until
they are available, what do you suggest I and other developers
without access to the kernel do?  Remember that we're all trying
to get products out the door, and most of us aren't security experts.

What usually happens, in fact, is that such applications have their
own encrypted-password file, but since it was set up by non-experts
in security, it is even less secure than /etc/passwd ever was.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jun 90 01:43:11 PDT
From:      [email protected]
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
Hmmm... I would vote for the creation of this newsgroup.  
*Because* I believe that the OSI 'migration' is doomed to go the way of the
Edsel.  While this does (like all of the other "we'll have OSI running
Real Soon Now" propaganda) run the risk that someone might actually take
the migration seriously, it also will provide a public forum in which to
demonstrate what is (and is NOT) actually happening.  Think of it as a 
'give 'em enough rope' strategy.  And as for a name, comp.protocols.migration,
please.  This 'comp.migration.to.iso' stuff is painful to read, as well as
completely breaking the naming system.

RichardT
This is just a test...
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 20:38:17 GMT
From:      [email protected]  (Tim Richardson)
To:        [email protected]
Subject:   TCPIP Driver -- VXWORKS
We're looking for a VXWORKS driver which supports tcp-ip protocols.  Does
anyone know of such a product?  We've been attempting to get WindRiver
to write one and so far they've been more than non-responsive.  We
are willing to purchase it, we're not looking for a freebe (but wouldn't
turn one down, of course).

I don't usually read these newsgroups, so please reply directly to the
address below.

Thanks,
-- 

Tim Richardson
VP Engineering
(415) 498-3200
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 21:01:23 GMT
From:      [email protected]  (Gerard A. Robinson)
To:        [email protected]
Subject:   Re: Duplicate Internet address on same network
In article <[email protected]> [email protected] (Steve Lodin) writes:
>
>I have two machines on my network using the same Internet address, and without
>network analysis tools, I am having trouble identifying the culprit.  Could
>somebody please tell me which manufacturer uses the Ethernet address
>AA:0:4:X:X:X.

That's the format of a DEC ethernet address after DECnet is done with it.
The X:X:X is typically a 0 followed by the 16-bit combination of the area
and node number 6bits of area and 10bits of node, little-endian.  DECnet
overrides the default ethernet address on the board with this result.  An
example for host 42.8 is AA:0:4:0:8:A8.

Gerard Robinson
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jun 90 06:18:58 -0400
From:      Scott Brim <[email protected]>
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
So are we going to follow through with the idea of running Net 10 in the
Boston Computer Museum (hooked up to the Internet) or not??
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 02:33:11 GMT
From:      [email protected]  (George Michaelson)
To:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
If an ASN.1 en/de coder is built to a specific and known subset of
ASN.1 which is what at least one message about SNMP implied, is it
any wonder it runs faster than a en/de coder written to try and handle
an *arbitrary* ASN.1 description? 

The same goes for the BER surely, if you know in advance what specific
sequences to expect you can afford to write an optimal package to read
and write those sequences, nasty hacks like pre-defined fixed buffers
that you write 2-3 bytes into and chuck onto the net without actually
"walking" all the ASN.1 involved.

ISODE is more than just SNMP support. If somebody writes fast generic
ASN.1 nobody will complain. meantime, its better than nothing. 

How does ISODE compare to Huitema's ASN.1 stuff for speed? ditto the
EAN code? Retix? is there are basis for benchmarking ASN.1 and BER
code?

George
-- 
ACSnet: [email protected]                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 Australia
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jun 90 09:43:15 PDT
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re:  Duplicate Internet address on same network
Steve Lodin:

AA:0:4:X:X:X = DEC  - logical addresses for systems running decnet

See RFC-1060 page 40.

--jon.
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 13:31:35 GMT
From:      [email protected]  (Joe Ragland)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]> [email protected] (Scott Brim) writes:
>So are we going to follow through with the idea of running Net 10 in the
>Boston Computer Museum (hooked up to the Internet) or not??

Gee Scott, that's sorta close to the water's edge.  A few ICMP redirects
and ole net 10 might just slide into Boston Harbor (that's "haba" to the
natives).

Actually, sounds like a great idea to me.

--joe
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 18:07:24 GMT
From:      [email protected]tut.cis.ohio-state.edu  (Dennis Ferguson)
To:        [email protected]
Subject:   Re: Quote
Torben Nielsen writes:
>From Kwang Sung's diatribe....
...
>Actually, I'm delighted you threw the following quote in there. Apparently
>from someone inside DEC:
>
>>The major reason for a slower than expected transition to OSI is the installed
>>base.  TCP/IP is only a small part of the installed base with 1500 networks.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>>DEC has sold 3,000,000 ethernet ports to 61k customers.

I quite enjoyed that note as well, not so much because I have particularly
strong feelings on the subject, but rather because if you rearrange the
paragraphs you get a little of the schizophrenia I often hear from vendors
and others with greater interest in the topic.  For example, compare the
above to the following, which appeared about 15 sentences later.

> The major reason why TCP/IP is so prevalent in computer networks today is
> not because it is technically superior than anything that was put out before.
> But because it was given away as standard equipment on millions of
> workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
> If not for this fact alone, there probably would not be ANY country wide
> interoperable protocol.

Or how about this

> The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
> are practically the same (so much the same that people don't see a benifit
> of using TP4 over TCP.)

and this

> TCP/IP will not support the upcomming applications such as multimedia as
> well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
> Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
> or take variously different routes (TCP/IP).

I think what is really needed is an ISO committee to standardize criticisms
of DoD IP for the advancement of OSI networking.  This way people could just
cite ISO 8992 instead of having to spend time rewriting all the same old
stuff, could be sure they were all saying the same bad things about TCP/IP,
and wouldn't get contradictory criticisms mixed up in the same eight
paragraphs.  Perfect.

Dennis Ferguson
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 18:35:53 GMT
From:      [email protected]  (David J. Farber)
To:        [email protected]
Subject:   Please not yet again
While I know it will not help to stop the religious wars, please take a peek at
the report produced by the Board on telecommunications and Computer
Applications of the National Research Council dated 1985 (work started
in 1983) titled:

Transport Protocols for the DOD Data Networks -- report to the DoD and the NBS

it compared TP/4 and TCP.

Dave



David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele:
215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8293;  Cellular:  302-740-
1198 "The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment." -- R. P. Feynman
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:23:45 PDT
From:      [email protected] (Mike Anello)
To:        [email protected]
Subject:   Remove from list
Please remove [email protected] from tcp-ip list. Thank you.
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 10:35:00 PDT
From:      [email protected]
To:        [email protected]
Subject:   National Research Council report on Transport Protocols
Dave:

That is RFC-942.

--jon.

----- Begin Included Message -----
Date: 10 Jun 90 18:35:53 GMT
From: [email protected]  (David J. Farber)
Subject: Please not yet again
To: [email protected]

While I know it will not help to stop the religious wars, please take a peek at
the report produced by the Board on telecommunications and Computer
Applications of the National Research Council dated 1985 (work started
in 1983) titled:

Transport Protocols for the DOD Data Networks -- report to the DoD and the NBS

it compared TP/4 and TCP.

Dave

David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele:
215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8293;  Cellular:  302-740-
1198 "The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment." -- R. P. Feynman
----- End Included Message -----

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 08:26:46 EDT
From:      [email protected] (Louis A. Mamakos)
To:        [email protected]
Cc:        
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
Its because of things like this that I wish the TCP-IP mailing list
would not be gatewayed to the USENET newsgroup comp.protcols.tcpip.
The S/N ratio has decreased steadily since it was gatewayed to the
newsgroup.

First of all, for the USENET folks, you should know that if you want
to create a new newsgroup, you should not hold discussion in
comp.protocols.tcpip, but in news.groups or something.  Post a pointer
to it, and carry on elsewhere.  Perhaps you don't know that the
newsgroup is also a mailing list?

comp.protocols.migrate.to.iso?  Well, sometime I think that the Milo
Medin view on this issue is correct; the ISO migration will turn out
to be from ISO BACK to TCP/IP when network users actually want to get
work done.  So much for my stand on that issue.

I remember when you could actually carry on a useful technical
discussion on this mailing list.  You know, implementations issues and
performance hack and the like.  Now, I know of many network weenies
who can't take the time to sort through the trash to find "useful"
messages.  So we don't read it very much at all.

Perhaps someone from DARPA, NSF, DoE, et al, could fund a person to
moderate the TCP-IP mailing list, making it useful once more.  Or
maybe we could form a new mailing list dedicated to what the TCP-IP
list used to be used for.  I realize now that the Internet protocol
suite has been "discovered" by the trade rags, there are lots of users
that need information.  I just think that there is still the need for
a forum for effective technical discussion.  And the [email protected]
mailing list doesn't seem to be the place to do it anymore.

Louis Mamakos
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 11:43:57 -0400 (EDT)
From:      [email protected]
To:        [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected]
Subject:   Re: Interesting uses of networking
The cs.cmu.edu Coke machine was hooked up to a computer by John Zsarnay
and/or Lawrence Butcher (now at Xerox PARC); essentially, the six little
out-of-product lights on the pushbuttons were monitored.  These would
flash on for a couple seconds while a particular bottle was dispensed,
and of course stay on when a column was empty.  They were connected, I
believe, to a terminal server machine that was programmed by Mike Kazar
to keep track of the time of the last transition (short-term and
long-term) for each column.  He and Dave Nichols put together a simple
[email protected]+(TM) protocol by which any machine on the local University-grant
Ethernet, and later the Internet as a whole, could probe the current
status of the machine; Dave wrote the program that became the ``coke''
command, which printed out the length of time since each column had been
totally empty.  (The idea, you see, was to notice when a column, having
gone empty, was refilled with (warm, room-temperature) Coke, because in
principle you wanted to select the coldest Coke available, and thus
avoid those colums that had recently been refilled.)  Ivor Durham, I
believe, wrote the Finger server that, if you fingered
``[email protected]'' would execute the ``coke'' command and
print out the column coldnesses.  I don't know who wrote the program,
which was one of the most-used Perq/Canvas applications, which displayed
the status of the (imputed) coldnesses as an array of bar graphs
displayed in the same layout as the selector buttons on the Coke machine
itself.  There was even a Gosling Emacs package that would run the coke
command for you and tell you, as a one-liner, where the coldest one was.

The Coke machine even had an internal holding bin, to combat the ``warm
Coke'' problem, such that it would never dispense the last two bottles
in a column.  Thus, to sense when a newly-loaded bottle would be
dispensed, you had to notice when the last two bottles had been
dispensed.  The protocol had a way to describe, separately, the imputed
coldnesses (the refrigeration time) of these last two bottles, and it
would recommend their use when appropriate.

Sure, there are dozens of hacks throughout the world, but I know
something about this one and it's fun.  As far as I can tell, Dave
Nichols spearheaded this one, having loved the idea of the SAIL (r.i.p.)
Pony.
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:06:48 EDT
From:      [email protected]  (James B. Van Bokkelen)
To:        Scott Brim <[email protected]>
Cc:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
	From: Scott Brim <[email protected]>

	So are we going to follow through with the idea of running Net 10 in
	the Boston Computer Museum (hooked up to the Internet) or not??

I don't know how receptive they'd be, or what their criteria for
noteworthy hardware is - when MIT shut down the last of the ITS 10s
(actually 2020s) last month, I was listening to someone there talk
about trying to give MC (KL10) to the museum, and being told "we
wouldn't mind having the front panel".  MC went to Sweden (a student
computer club in ?Malmo?), where I believe it is running again.

If they are interested, MIT is presently looking for a home for 10.2.0.6,
among others (10.0.0.44 is gone), but if they aren't, maybe we should
try to get ARPA to give two or three IMPs to the Swedish hackers...

James B. VanBokkelen				FTP Software Inc.
[email protected]					617-246-0900
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:38:36 EDT
From:      Bob Stewart <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Duplicate Internet address on same network
The Ethernet AA-00-04 indicates a DECnet node, with its Ethernet address
"locally administered" to contain the DECnet node number.  You'll find the
fourth byte is a zero.  The last two bytes are the DECnet node number, in, of
course, little-endian form.  The high order 6 bits of the last byte are the
DECnet area.  The rest of the bits are the DECnet node within that area.

(This should be close, its from memory and looking at a sample of one DECNet
node.)

	Bob

-----------
Bob Stewart ([email protected])
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:48:38 EDT
From:      [email protected]
To:        Dan Lynch <[email protected]>, [email protected]
Subject:   Re: toll restrictors
>I'm sure Unix could be hacked a bit to do the same as Tenex did many
>years ago.

>Dan
>-------


assuming, ofcourse, that you have enough of the sources . . . .. 


stev

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 21:10:20 -0700
From:      [email protected] (Merton Campbell Crockett)
To:        [email protected], [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
Maybe we could get three systems and have one set-up as "cambridge-mb", one as
"reston-mb", and one as "moffett-mb".  We could then have a perpetual trace-
route running with constant redirects between Cambridge and Reston with Moffett
as the, occassional, side-line judge.

Those on the ARPA side may not appreciate the humour of the last days of this 
net as seen from the MILNET side--unfortunately one has attendency to remember
the wierd or worst events.

Merton
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 09:56:30 GMT
From:      [email protected]  (Joe Smith)
To:        [email protected]
Subject:   Re: tftp (was Re: anonymous ftp, and the dangers thereof)
In article <[email protected]> [email protected] (Anton Rang) writes:
>In article <[email protected]> [email protected] (The Grey Wolf) writes:
:  At a minimum, you should restrict either which hosts can access tftp
:on a given machine, or which files tftp can access.  The problem is
:that tftp, as distributed, lets anyone access any publicly-readable
:file, and lots of important files (like /etc/passwd) are publicly
:readable.  (In other words, having tftp enabled allows dictionary
:attacks to be tried without needing an account on the remote machine.)
:  This is my understanding of the matter, at least; feel free to
:correct any misapprehensions.

As distributed from Sun, tftp does NOT allow access to /etc/passwd.
It does a chroot to /tftpboot first.  This means that if you attempt to
read /etc/passwd, the kernel translates it to /tftpboot/etc/passwd, which
does not exist.  The chroot call also means that ".." cannot be used to
get out of set directory.  See "man 2 chroot".

-- 
Joe Smith (408)922-6220 | SMTP: [email protected] or [email protected]
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C41    | BIX: smithjoe | 12 PDP-10s still running! "POPJ P,"
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 16:44:27 -0400
From:      "Martin Lee Schoffstall" <[email protected]>
To:        [email protected] (Welch)
Cc:        [email protected]
Subject:   Re: How about comp.internet?
Actually comp.internet would also serve an additional (smaller) purpose,
many of the Internet providers have newsgroups that are regional
in distribution that might be interested in posting to something
like:
	comp.internet.psinet
	comp.internet.nearnet
	comp.internet.nordunet
etc.....

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

 In article <[email protected]>,
 [email protected] (Louis A. Mamakos) writes:

 >I remember when you could actually carry on a useful technical
 >discussion on this mailing list.  You know, implementations issues and
 >performance hack and the like.

 >... Or maybe we could form a new mailing list dedicated to what the TCP-IP
 >list used to be used for.  I realize now that the Internet protocol
 >suite has been "discovered" by the trade rags, there are lots of users
 >that need information.

 I agree that there is a real need for both a general Internet news group
 and a technical group.  However, I think the best solution would be
 to move all the non technical discussions to a new newsgroup, and let
 TCP-IP return to what it once was.

 Why not create a new group (and mailing list) called comp.internet?

 In general, comp.internet should be for the users and administrators of
 the Internet and comp.protocols.tcp-ip should be for the developers of
 TCP/IP hardware and software.

 Curt Welch
 [email protected]
 David Taylor Research Center (A Navy Lab)
 Bethesda, MD
 (301) 227-1428
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 11:08:11 GMT
From:      [email protected]  ( Graham Jack)
To:        [email protected]
Subject:   A future standard for UNIX TCP/IP?
I hear a rumour that the 4.4BSD TCP/IP is intended to be compliant
with the Host Requirements RFCs (I'm not sure if that included both
RFCs or just RFC1122).
Given the status of the current 4.3BSD TCP/IP as something of a
'functional standard' for UNIX (and other) implementations, it would be
worth a small wager that an enhanced (compliant) 4.4BSD TCP/IP will
be the standard of the future.
If I were a UNIX supplier and I had to choose between fixing my
current port to meet the HRs or hanging on for a new BSD version....
I also heard that 4.4 is to include support for OSI protocols, this
begins to sound too good to be true.

What is the status of 4.4BSD, is there going to be one, does it exist
yet? Does anyone out there have any advance information on what 4.4BSD
might add to the current standard of TCP/IP implementation?

	    Graham Jack, Data Logic.
	    <[email protected]>
-- 
Regards,
	    Graham Jack, Data Logic.
	    <[email protected]>
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 12:06:59 GMT
From:      [email protected]  (Christian Huitema)
To:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1.
A few comment on the efficiency of ASN.1. We did quite a lot of work on
that at INRIA, including the development of alternative encoding rules.
The relative cost of ASN.1 derives from the recursive
``type-length-value'' structure of the BER, plus the cost of decoding
length fields, integers, and reals. The relative cost of ASN.1, compared
to a simpler encoding, depends from the type of elements. To cite, in order:

* the handling of REALs is ludicrous. It is almost equivalent to
converting them to string using something like <sprintf/sscanf>, only
more complex.

* the handling of the Integers, as explained by MTR, uses variable
length big endian complement to 2 notation. The coding can be optimized
somehow, e.g. by predicting the range of the element or by loosening
your compliance to the BER (as advocated by some experts from DEC); the
decoding routines on the other hand must be general. Their cost depends
from the quality of the implementation; I measured a ration of 10 to 20
between BER decoding of integers and a simple ``move''; an endian
reversion would have costed 5 to 6 moves.

* the handling of the strings is comparable to what can be found in
other syntaxes: the coding of the tag and length field may take 20
instructions instead of 1 or 2, but it is outweighted by the copying of
the string itself, which is syntax independant. The decoding can however
be made much longer if your partner insists on passing its strings as
``sequences of segments''.

* the handling of structures requires an analysis of the tags and length
fields. A sequence without optional components has a very low cost; a
set is very costly; a choice cost marginally more than a ``case of''
operation; an array (set of, sequence of) costs significantly longer to
decode than a simple ``count + pointer'' representation, as one can only
assert the number of elements (useful for malloc, bound checking, etc)
by decoding each element and testing the ``length'' field.

In short: the efficiency of ASN.1/BER depends of the complexity of the
structure and of the type of the element. If a simple structure contains
mostly strings, ASN.1 is very efficient. If a semi complex structure
contains a mix of strings and integers (or booleans), one can expect 1
to 4 instructions per byte -- depending of the mix. If the message is a
matrix of floating point numbers exchanged between a Cray and a
graphical workstation, then ASN.1 is about as good as converting the
matrix to a text file... In short, if the application deals mostly with
numbers, one should try to negociate something else than the BER.

For information handling protocols like MHS, X.500, DFR or CMIP (and
SGMP) the cost of the encoding is probably in the 1-4 inst/byte range.
This is  significant, although probably much less than the cost of
retrieving the information itself. And one should point out that the
coding of the DNS is about as costly...

Christian Huitema
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 20:15:52 PDT
From:      [email protected] (Kwang Sung)
To:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
>From: [email protected] (Bob Sutterfield)  wrote:
>Sender: [email protected] (USENET Administrator)
>Organization: Morning Star Technologies


Hi...

	Upon Bob's request, I would like to take a normal procedure in order
to create a new newsgroup "comp.protocols.iso.migration" so that nobody can
bother existing newsgroup either "comp.protocols.iso" or "comp.protocols.
tcp-ip" any more.

>if its regular readers were calling for help in the form of another,
>more focused group and list (they aren't), then the group should be
>called comp.protocols.iso.migration, in order to fit in with the
>established naming structure.

>I'd suggest you follow the common newsgroup creation procedure: set up
>a mailing list, broadcast its existence to all appropriate, interested
>forums (e.g. the existing ISO forums), and invite all interested
>parties to join.  When the traffic becomes too heavy for members'
>mailboxes, you'll have a particularly strong case to call for a new
>newsgroup.  At that time, ask someone to help you set up a gateway
>between your iso-migration list and the new c.p.i.m newsgroup.  And
>you have my permission, in advance, to say "I told you so" :-)

>You have asked the folks there whether they're interested in
>segmenting their discussions.  From their responses, I see neither the
>need or the mandate.

	First of all, this new newsgroup can be grouped by anybody who is
interested in migration/transition to OSI. You may discuss any technical
or non-technical issues on any protocols/strategies which might be helpful
to migrate/transit to OSI world. Here are about 40 persons who responded to
my postings so far. I would like to vote whether we need to create such a new 
newsgroup.  Please vote, and e-mail either me or post temporarily at 
"comp.protocols.iso", NOT at "comp.protocols.tcp-ip". After I collect those
info, I will re-post the result at both "comp.protocols.iso" and 
"comp.protocols.tcp-ip". Here is the mailing list, and if you are interested
in joining this new newsgroup, please vote.

------------------------------------------------------------------------------

[email protected] (Bob Sutterfield)
[email protected] (Fred R. Goldstein)
[email protected]
[email protected] (Chris Perry)
Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
Bill Streilein <nsc!wellfleet.com!bstreile>
[email protected] (Cliff Frost {415} 642-5360)
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)
[email protected] (Dennis Ferguson)
[email protected] (Einar Stefferud)
uunet!proteon.com!gmalkin (Gary Scott Malkin(GONE))
[email protected] (David Grieve)
uunet!wrs!yuba!hwajin (Hwa Jin Bae)
att!lzaz!jer
[email protected] (Lynn Jessop)
uunet!unx.dec.com!jjf (8N8-FRANEY)
nsc!asylum.sf.ca.us!karl (Karl Auerbach)
[email protected] (Keith Brown)
Hakiml Laraqui  <uunet!sics.se!laraqui>
ncr-sd!ncrcae!lhybl
[email protected] (Louis A. Mamakos)
uunet!uu.psi.com!schoff (Martin L. Schoffstall)
David Hayes <uunet!csvax.seas.smu.edu!merlin>
uunet!ukc.ac.uk!mhs
[email protected] (Marshall Rose)
[email protected] (Clement Vaillancourt)
[email protected] (Russ Nelson)
[email protected]
[email protected] (Gene Saunders)
[email protected] ("Martin Lee Schoffstall")
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>
[email protected] (Torben Nielsen)
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)
[email protected] (Amanda Walker)
[email protected] (Welch)

--------------------------------------------------------------------------------

>In summary, we should continue discussing migration issues in the
>existing forum.  When the popular mandate arises for a new forum,
>create it as a mailing list.  When the mailing list becomes too busy,
>establish a gateway to a newsgroup named comp.protocols.iso.migration.

	Thanks, Bob... and, from my previous postings, I would like to
apologize to some persons, if they felt hurt from me. I am sure this new
newsgroup will resolve our networking future, and will give us a right 
direction. Thanks.



					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

--------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 14:21:36 GMT
From:      [email protected]  (Joshua L Mindel)
To:        [email protected]
Subject:   Wollongong TCP/IP WIN/3B 3.0 - UUCP/TCP/IP password capability?
I'd like to use UUCP for file transfers between AT&T 3B2s interconnected
via TCP/IP.

MY QUESTION:  Is there any way to specify a password in the uucico command?

The AT&T Enhanced TCP/IP WIN 3B Installation/Administration guide provides
steps to set-up UUCP over TCP/IP on a 3B2 in a trusted environment.
In this context, a trusted environment is one in which password protection 
is not required.

The WIN software utilizes the standard UUCP programs and datafiles,
but disregards the chat script in the Systems file.  Instead, the userid
that uucico uses to login to a remote machine is specified in the uucico
command itself (via the -u option).  The password requirement on the remote end
is bypassed somehow by the WIN software.  The end result is that two 
nodes running UUCP/TCP/IP can establish a communications link via address and 
userid only; whether or not a password is associated with that userid.

A broader question:  Is there any means by which to utilize passwords in
UUCP/TCP/IP communications?   uucico seems the most obvious place to me.
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 14:24:43 GMT
From:      [email protected]  (Joshua L Mindel)
To:        [email protected]
Subject:   UUCP/TCP/IP question:  oops, my signature didn't get included
Hi, I just posted the question concerning passwords with UUCP over TCP/IP
on AT&T 3B2s.  Unfortunately, I don't believe that my signature got
included in the message before it was sent out.

-------------------------------------------------------------------------------
Joshua L Mindel				Internet:  mindel%[email protected]
Senior Analyst				Usenet:	   uunet!netwrx1!mindel
NetWorks One				Phone:     (703) 827-7767
8229 Boone Blvd., Suite 810 		Fax:	   (703) 790-9372
Vienna, VA  22182 
-------------------------------------------------------------------------------
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 14:33:14 GMT
From:      [email protected]  (Bob Sutterfield)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In article <[email protected]> [email protected] (Kwang Sung) writes:
   Recently, I've proposed a new newsgroup
   "comp.protocols.migrate.to.iso".

      From: Amit Parghi <[email protected]>

      Don't use the name "comp.protocols.migrate.to.iso"; since there
      are already groups under "comp.protocols.iso", call it
      "comp.protocols.iso.migration".

If comp.protocols.iso and its associated mailing list,
[email protected], were swamped with transition traffic (it isn't) and
if its regular readers were calling for help in the form of another,
more focused group and list (they aren't), then the group should be
called comp.protocols.iso.migration, in order to fit in with the
established naming structure.

   First of all, I would like to show some responses in order to prove
   why we need to create those new newsgroup.

I'd suggest you follow the common newsgroup creation procedure: set up
a mailing list, broadcast its existence to all appropriate, interested
forums (e.g. the existing ISO forums), and invite all interested
parties to join.  When the traffic becomes too heavy for members'
mailboxes, you'll have a particularly strong case to call for a new
newsgroup.  At that time, ask someone to help you set up a gateway
between your iso-migration list and the new c.p.i.m newsgroup.  And
you have my permission, in advance, to say "I told you so" :-)

I suspect that the existing list and group facilities are able to
manage the traffic.  In fact, "the impending IP-ISO transition" is one
of the topics of comp.protocols.iso and its associated mailing list.
You have asked the folks there whether they're interested in
segmenting their discussions.  From their responses, I see neither the
need or the mandate.

In summary, we should continue discussing migration issues in the
existing forum.  When the popular mandate arises for a new forum,
create it as a mailing list.  When the mailing list becomes too busy,
establish a gateway to a newsgroup named comp.protocols.iso.migration.
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 15:44:16 GMT
From:      [email protected]  (Welch)
To:        [email protected]
Subject:   How about comp.internet?
In article <[email protected]>,
[email protected] (Louis A. Mamakos) writes:

>I remember when you could actually carry on a useful technical
>discussion on this mailing list.  You know, implementations issues and
>performance hack and the like.

>... Or maybe we could form a new mailing list dedicated to what the TCP-IP
>list used to be used for.  I realize now that the Internet protocol
>suite has been "discovered" by the trade rags, there are lots of users
>that need information.

I agree that there is a real need for both a general Internet news group
and a technical group.  However, I think the best solution would be
to move all the non technical discussions to a new newsgroup, and let
TCP-IP return to what it once was.

Why not create a new group (and mailing list) called comp.internet?

In general, comp.internet should be for the users and administrators of
the Internet and comp.protocols.tcp-ip should be for the developers of
TCP/IP hardware and software.

Curt Welch
[email protected]
David Taylor Research Center (A Navy Lab)
Bethesda, MD
(301) 227-1428
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 16:49:48 GMT
From:      [email protected]  (Dave Kell)
To:        [email protected]
Subject:   SLIP reliability
Does SLIP have the same level of error detection and correction that
ethernet-based IP has?

Dave Kell
MPR Teltech Ltd.
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 17:14:38 GMT
From:      sdd.hp.com!u[email protected]ucsd.edu  (Kent England)
To:        [email protected]
Subject:   Re: Multiple IP networks on one Ethernet interface
In article <[email protected]>,
[email protected] writes:
> ... I would like to know if any of
> the commercially-available TCP/IP packages have the capability of either:
> 
>      1)  sending and receiving IP packets for more than one subnetwork
>          over the same Ethernet interface.
> 
>  or: 2)  routing packets between two or more subnetworks over the
>          same Ethernet interface.
> 
> We have several spare Ethernet bridges but only one router - a Cisco.

	Multiple subnets on a single interface is a feature of the latest
cisco software.  Look in the manual update section, not the manual.  It
is the primary/secondary designation of the ip-address of a given
interface.
 ...
> We also run WIN/TCP for VAX/VMS and Control Data's TCP/IP product.  Can
> either of these be configured for multiple subnets on one interface?
> 
	Rather than configure each host to be a member of each subnet on 
the given wire, I would recommend setting the subnet mask such that each
host on the wire would ARP for all directly connected hosts.

	You could simply set the subnetmask to the netmask (ie, no subnet)
on each host on the LAN and let the router proxy for any nonlocal destinations.
This seems to me to be a cleaner approach than creating multiple addresses 
for each host on the shared subnets.

	This will not work for multiple networks, only subnets.
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 17:22:33 GMT
From:      [email protected]  (Kent England)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]>, 
[email protected] (Scott Brim) writes:
> So are we going to follow through with the idea of running Net 10 in the
> Boston Computer Museum (hooked up to the Internet) or not??

	I think it is a great idea.  If you know a contact there, I would
talk to them.

	But if that doesn't pan out, it shouldn't be too hard to create a
net 10 routing loop inside BBN somewhere.  I think an occasional ping packet
would feel right at home wandering around inside 10 Moulton Street somewhere.
:-)  Does that seem appropriately respectful?  (Certainly no disrespect
intended to BBN.)

	--Kent England, Boston University
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 17:52:50 GMT
From:      [email protected]  (Fred R. Goldstein)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"[Part 1]
In article <[email protected]>, [email protected] (Kwang Sung) writes...
>	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
>I've received so many responses. Among those, I've selected some best ones, 
>after I've thrown out some bad ones. I couldn't reply to all of you, since it's
>so many. However, I might be able to answer thru this network. I think some 
>people still don't understand how/where this networking world is going to. 
>Absolutely, and positively, the world is moving toward one OSI world !!,
>even if ISODE has screwed up OSI world a little bit. 

John Franey, who works for the same company that I do (and I don't
think either of us is speaking officially here!) says, 
>TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

That basically is wrong.  TCP/IP is connectionless (CL) at the top of the 
network layer.  OSI offers BOTH CO and CL services.  DECnet/OSI provies
the CLNS, not unlike IP.  It also supports the CONS when needed for
compatibility, but its "native language" is connectionless.  ISO settled 
the CLNS/CONS war by standardizing both.  And multimedia is irrelevant.
If anything, the higher speeds possible in CLNS tend to make it more
applicable for multimedia than CONS, which is X.25-based.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  

While I'm not a spokesman, I do work for DEC in communications 
engineering.  We have certainly taken a leading role in OSI.  But we
are also building TCP/IP.  And while Phase V is OSI up to Layer 3 it
supports OSI and non-OSI in parallel using a "towers" approach.  Most
DEC-DEC applications won't use the OSI upper layers.  Note that it's
the upper layers of OSI that are most controversial.

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.

The PTTs only own their own internal networks.  They provide X.25
subnetworks.  In OSI terminology (see ISO8648) ANY public network
is just a subnetwork; you may run an NS-protocol on top of it.  So
you can run OSI-CLNS (ISO8473, found in DECnet/OSI) and be fully
OSI compliant, or you can run IP above it and be fully TCP/IP compliant.
The PTTs have no say in what you do above their subnet layers.  
Datagrams are not easy to bill for, so the subnet is still CO.

I post this because I don't think the terms of reference of this debate 
should be based on misinformation, like "OSI is connection-oriented"
or "PTTs won't allow TCP/IP to be used in Europe."  OSI CLNS + TP4
is not very different (semantically) from IP and TCP.  They provide a
growth path, especially since IP addressing has obvious limitations.  
But they also provide coexistence.  TCP/IP is a valued technology and
while comp.protocols.osi.migration might be a good group to have,
extremist anti-TCP/IP rhetoric will make the transition harder and more
painful for all involved. 
---
Fred R. Goldstein   [email protected] 
                 or [email protected]
                    voice:  +1 508 486 7388 
opinions are mine alone; sharing requires permission
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 19:56:50 GMT
From:      [email protected]  (Kurt Baumann)
To:        [email protected]
Subject:   Re: X Windows and TCP/IP on the Macintosh
In article <[email protected]>, [email protected] (Bob Stewart) writes:
> Dear Generous Suppliers of Free Advice,
> 
> I'm using NCSA Telnet on my Macintosh to talk to a Unix system so I can
> communicate with the world.  It's connected through AppleTalk to a Gator Box.
> I'd like to have a more direct connection for mail, FTP, etc., as well as 
> X Windows access.
> 
> We're looking into White Pine Software's eXodus, which implements X Windows
> over a communication base such as Alisa Systems' TSS for DECnet or Apple's
> MacTCP for the Internet.  I'd like to hear from people who've tried that or
> who know anything interesting about it.  If I have MacTCP, can I run FTP,
> Telnet, eXodus, and such just as if I was on a Real :-) System?  If so, can
> they all run at once?  White Pine tells me that eXodus/MacTCP and NCSA Telnet
> are mutually exclusive.  If anyone from Apple or White Pine cares to respond,
> I won't consider it as a commercial message.
> 

Here is the scoop.  If you are using NCSA Telnet with the builtin NCSA TCP/IP
stack, then you cannot also use anything that uses MacTCP.  If, however,
you either get a commercial product that uses MacTCP (like TCP/Connect II,
or the UB product) or you get the NCSA Telnet that uses MacTCP, then you
can use other programs that use MacTCP at the sametime.  As far as I am aware
there should be no problem in using eXodus with other MacTCP compatable
products.

Hope that helps.

Kurt Baumann--
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 21:18:49 GMT
From:      [email protected]
To:        [email protected]ddn.mil
Subject:   OSI Transition mail group
In article <[email protected]>, [email protected] (Kwang Sung) writes:
> Yes. I am so serious. We need to create a new newsgroup "comp.protocols.
> migrate.to.iso". For instance, recently I've designed and implemented RDA 
> (ISO/IEC DP 9579-1) on top of SunLink OSI and TCP/IP with RFC 1006 on my 
> SPARCstation 1. Actually, I've embedded it into ISODE 6.0.  However,
> a lot of customers wanted to put it on top of lpp (RFC 1085). I have a trouble
> with finding those specific bridges between RFC 1085 and "pure" OSI stack.
> If we create those new newsgroup, then we can have an info on migration from
> "old" TCP/IP technology, SNA, or other protocols to "new" OSI technology.
> As far as I know, application gateways, transport gateways, network tunnels,
> protocol tunnels, etc are the only primitive methods for the migration. 
> Actual environment needs higher technology.

I think such a group might not be too inappropriate. I am in the middle of
planning such a migration for a multi-thousand node global network, and while I
don't expect things to happen instantly, it's time to start looking at the
issues.

As far as the group name, I might suggest comp.protocols.iso.transition. It
fits the existing structure much better (I think). I prefer transition to
migration because the birds keep migrating back and forth and if we make it to
ISO, we plan to stay there.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: [email protected]
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 21:49:49 GMT
From:      [email protected]  (George Powers)
To:        [email protected]
Subject:   Re: Out Of Band data processing.
From excelan!zaphod.mps.ohio-state.edu!samsung!uunet!ogicse!littlei!intelisc!isc.intel.com!joel Mon Jun 11 13:26:24 PDT 1990
Article 3226 of comp.protocols.tcp-ip:
Path: excelan!zaphod.mps.ohio-state.edu!samsung!uunet!ogicse!littlei!intelisc!isc.intel.com!joel
>From: [email protected] (Joel Clark)
Newsgroups: comp.protocols.tcp-ip
Subject: Out Of Band data processing.
Message-ID: <[email protected]>
Date: 7 Jun 90 20:24:42 GMT
Sender: [email protected]
Distribution: na
Organization: Intel Scientific Computers, Beaverton, Oregon
Lines: 28



Two questions regarding Out Of Band data processing.

1) If a socket has the OOBINLINE option set and a user calls recv() on it
   with the MSG_OOB flag set, what should be returned to the recv() call?
	An error? which error?
	The next data in the INLINE Queue?

2) If a socket does not have the OOBINLINE option set and a user calls 
   recv() on it with the MSG_OOB flag set and there is no Out OF Band data
   what should happen?

	The recv() call blocks waiting for Out Of Band data unless the
	socket is NON-Blocking in which case the recv call returns
	EWOULDBLOCK in errno?

	The recv() call returns zero bytes immediately?

	The recv() call returns an error? which error?

Please Email if possible and I will summarize for the net.

Joel Clark
Intel Scientific Computers
Beaverton, Or. USA
(503) 629-7732
[email protected]


--
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!novell!george  George Powers
Internet: [email protected] 
--
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 07:58 PDT
From:      Michael Stein                        <[email protected]>
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
Net 10 is a class A network number.  As we run out of network
numbers someone is going to need it, don't stick it in some
museum.  I'm sure that if anyone asked there would be lots
of volunteers who could turn in several class B network numbers...
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 02:44:48 GMT
From:      [email protected]  (John Chambers)
To:        [email protected]
Subject:   Re: desperately need an answer
In article <[email protected]>, [email protected] writes:
> Clark, in his RFC 817, said that kernel implementation
> of TCP/IP would subject to many system limitations and
> suggested that only part of TCP/IP should be placed in
> the kernel, leaving the rest in the user processes.
> 
> Now, what I don't understand is that why everybody still
> put the entire TCP/IP in the kernel - AT&T system V,
> Sun BSD Unix and many others all does just that. Does
> that mean that those limitations are never faced by them
> or that they have actually took his advice but provided the
> interfaces to the user processes in a way that gives
> them the illusion of interfacing with the kernel ?

This one's easy.  People are paid more for kernel work than they
are for application-level work, so they have a strong incentive
to do as much work there as possible.  I've seen a lot of this,
and it goes a long way to explain why Unix kernels are becoming
so bloated.  When you reward people better for using method A
than for methods B, C, ..., it should come as no surprise that
they will tend to use method A.

Until a few years ago, I foolishly took the approach of doing
work wherever it seemed best, and this was almost never inside
the kernel.  After a while, I noticed that the main effect of
this was to make it clear to prospective employers that I was
a kernel lightweight.  Now I know better.

(Note the lack of :-)s above. ;-)

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 03:04:34 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   Vote for/against "comp.protocols.iso.migration"
>From: [email protected] (Bob Sutterfield)  wrote:
>Sender: [email protected] (USENET Administrator)
>Organization: Morning Star Technologies


Hi...

	Upon Bob's request, I would like to take a normal procedure in order
to create a new newsgroup "comp.protocols.iso.migration" so that nobody can
bother existing newsgroup either "comp.protocols.iso" or "comp.protocols.
tcp-ip" any more.

>if its regular readers were calling for help in the form of another,
>more focused group and list (they aren't), then the group should be
>called comp.protocols.iso.migration, in order to fit in with the
>established naming structure.

>I'd suggest you follow the common newsgroup creation procedure: set up
>a mailing list, broadcast its existence to all appropriate, interested
>forums (e.g. the existing ISO forums), and invite all interested
>parties to join.  When the traffic becomes too heavy for members'
>mailboxes, you'll have a particularly strong case to call for a new
>newsgroup.  At that time, ask someone to help you set up a gateway
>between your iso-migration list and the new c.p.i.m newsgroup.  And
>you have my permission, in advance, to say "I told you so" :-)

>You have asked the folks there whether they're interested in
>segmenting their discussions.  From their responses, I see neither the
>need or the mandate.

	First of all, this new newsgroup can be grouped by anybody who is
interested in migration/transition to OSI. You may discuss any technical
or non-technical issues on any protocols/strategies which might be helpful
to migrate/transit to OSI world. Here are about 40 persons who responded to
my postings so far. I would like to vote whether we need to create such a new 
newsgroup.  Please vote, and e-mail either me or post temporarily at 
"comp.protocols.iso", NOT at "comp.protocols.tcp-ip". After I collect those
info, I will re-post the result at both "comp.protocols.iso" and 
"comp.protocols.tcp-ip". Here is the mailing list, and if you are interested
in joining this new newsgroup, please vote.

------------------------------------------------------------------------------

[email protected] (Bob Sutterfield)
[email protected] (Fred R. Goldstein)
[email protected]
[email protected] (Chris Perry)
Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
Bill Streilein <nsc!wellfleet.com!bstreile>
[email protected] (Cliff Frost {415} 642-5360)
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)
[email protected] (Dennis Ferguson)
[email protected] (Einar Stefferud)
uunet!proteon.com!gmalkin (Gary Scott Malkin(GONE))
[email protected] (David Grieve)
uunet!wrs!yuba!hwajin (Hwa Jin Bae)
att!lzaz!jer
[email protected] (Lynn Jessop)
uunet!unx.dec.com!jjf (8N8-FRANEY)
nsc!asylum.sf.ca.us!karl (Karl Auerbach)
[email protected] (Keith Brown)
Hakiml Laraqui  <uunet!sics.se!laraqui>
ncr-sd!ncrcae!lhybl
[email protected] (Louis A. Mamakos)
uunet!uu.psi.com!schoff (Martin L. Schoffstall)
David Hayes <uunet!csvax.seas.smu.edu!merlin>
uunet!ukc.ac.uk!mhs
[email protected] (Marshall Rose)
[email protected] (Clement Vaillancourt)
[email protected] (Russ Nelson)
[email protected]
[email protected] (Gene Saunders)
[email protected] ("Martin Lee Schoffstall")
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>
[email protected] (Torben Nielsen)
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)
[email protected] (Amanda Walker)
[email protected] (Welch)

--------------------------------------------------------------------------------

>In summary, we should continue discussing migration issues in the
>existing forum.  When the popular mandate arises for a new forum,
>create it as a mailing list.  When the mailing list becomes too busy,
>establish a gateway to a newsgroup named comp.protocols.iso.migration.

	Thanks, Bob... and, from my previous postings, I would like to
apologize to some persons, if they felt hurt from me. I am sure this new
newsgroup will resolve our networking future, and will give us a right 
direction. Thanks.



					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

--------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 03:10:21 GMT
From:      [email protected]ut.cis.ohio-state.edu  (John Chambers)
To:        [email protected]
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <[email protected]>, [email protected] (Barry Margolin) writes:
> In article <[email protected]> [email protected] (Steven M. Schultz) writes:
> >just a "thought" - if the (shadow)file is non-world readable and the
> >system is administered "correctly" then why bother with
> >encryption at all ;-)
> 
> I'm not sure how non-serious that smiley represents.  The serious answer is
> that even system administrators should not be able to find out a user's
> password.  Sure, they don't need to know the user's password to violate the
> user's files.  But if they know someone's password then they could
> accidentally (or through coercion) divulge it to someone else.

Some years back, I saw an enlightening instance of all of the above.
The participants shall remain nameless; the OS was Univac's EXEC8 on
the 1108, for which every file had both a read and a write password.
The system stored these internally in an unencrypted form, and one
of the local games was to try to find holes in the system that let
one access them.  One of the holes was intentional:  There was a
system utility that would list files and their passwords, so that
an administrator could delete files.  One administrator was rather
unpopular with users; and one day he got a bunch of guys in the
EE and physics departments especially mad at him, so they changed
their files to have a read password that was a well-known sexual
verb starting with 'f', and a write password that was his name.
They took no further action.

At the next campus-wide users-group meeting, he got into a dispute
with some of them, and in the heat of the moment, he made some rather
disparaging remarks about the nature of people who would use obscene
insults about him as their passwords.  They didn't respond.

The next day, they all wrote letters to his superiors complaining about
the fact that he had, in a public meeting, made statements that enabled
listeners to guess the passwords on their files.  It was perhaps just a
coincidence, but in very short order he no longer worked there.

Myself, I was satisfied with finding one way to do raw disk I/O that
showed a few such passwords, then I went on to more interesting work.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 10:07:39 -0400
From:      [email protected] (Sze-ying Wuu)
To:        [email protected], [email protected]
Subject:   Re: Dial up access to Internet facilities
>	CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
>	a script every night which brings up the dial-up line, and then opens
>	a connection to a port on relay.cs.net and tells it to start delivering
>	mail to the site.  The application at that connection starts up the
>	appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
>	where a channel typically has messages destined for a particular site),
>	which delivers the mail to the site.  [Note there's no security problem
>	here -- anyone can start up the channel, but the channel will only deliver
>	to the proper remote system(s)]
>
>	Craig
>


Does CSNET uses Phonenet protocol for dial-up sites? 

We have 1986 version of MMDF, is there a newer version available from
pulic domain? I assume with MMDF, we still need MX RR for a host to
accumulate mail for all dial-up sites. Is there a limitation on the
number of channnels can be fired up? 

Sze-Ying Wuu
JvNCnet
[email protected]
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 03:46:59 GMT
From:      [email protected]  (John Chambers)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]>, [email protected] (Liudvikas Bukys) writes:
> In article <[email protected]> [email protected] (John Chambers) writes:
> >The obvious counter-example to this is /usr/spool/uucppublic, which
> >is almost always world-writable, yet there seem to be no reports of
> >even minor problems with this.  It's usually considered a useful
> >part of uucp, and an assortment of tools are around (uuto/uupick for
> >example) are layered on top of it.
>
> 1.  Here's one "minor problem" report: I have heard that .rhosts
>     files have been uucped into ~uucp.  Think about it.

Yeah; I've often wondered about the practice of making ~uucp be
/usr/lib/uucppublic, and this is just one of the reasons why this
isn't a good idea.  Even if you aren't on the internet, consider
uucping something into ~uucp/.profile, ~uucp/.cshrc, etc.

The most basic uucp security says that you only allow the world
to write to /usr/lib/uucppublic, which is nobody's home directory.
(Of course, since Sun started selling systems on which "nobody"
is a valid login, this rule should perhaps be rephrased... :-)
Trusted users might be allowed access to other directories, such
as their own home directories.  But for your own sanity, you should
try to prevent the copying of files (especially accidentally) into
uucp's home directory.  Security aside, correcting the problems when
someone duplicates a filename there can be really crazy.

This isn't unique to uucp, of course.  I've seen several cases of
people building email systems with an administrative pseudo-user,
whose home directory was the mail spool directory.  It seems like
a good idea until a higher-level package uses a file-name convention
that produces a name that matches one of the control (or source ;-)
files.  This can be surprisingly difficult to avoid, considering
that packages typically come from several sources.  "What do you
mean, you set up `Systems' and `Dialers' accounts right after we
merged /usr/spool/mail with /usr/lib/uucp?"  It's a good idea to 
separate home directories from working directories, if you want 
to get it all working.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 04:59:34 GMT
From:      [email protected]  (George Michaelson)
To:        [email protected]
Subject:   Please, no more transit vs migrate smirking
If I hear/read one more article from <arbitrary wise-old-owl> 
about transit vs migrate I gonna go off pop.

Migrate is appropriate when you behave like a flock of sheep about 
something, have random goats to be separated out, shepherds pushing 
you into small confined spaces, with snarling dogs nipping your heels, 
and have a bunch of lone wolves picking off stragglers along the edge. 

It also applies to large flighty crowds that head around aimlessly, 
following a leader blindly on faith, and split up into a zillion separate 
paths when attacked, and also the ones that seem to keep coming back year 
after year to the same old turf. 

Sounds like network debates to me...

Around here, OSI is like buying this years vintage:

	-Tastes awful when you sample, but your nose tells
	 you its going to improve with age.

Enough mixed metaphors.

George
-- 
	G.Michaelson
Internet: [email protected]                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          The University of Queensland, St Lucia, QLD Australia 4067. 
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 07:07:19 GMT
From:      [email protected]  (Phil Karn)
To:        [email protected]
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
I also support the creation of a "comp.protocols.migrate-to-osi" newsgroup.
The longer we can keep the OSI cheerleaders preaching to themselves, the
less damage they'll be able to wreak among the rest of us who are building
real networks, supporting real users, and solving real problems instead of
artificial ones.

And during slow moments it'll always be good for a laugh; perhaps somebody
can excerpt the better items for rec.jokes.funny.

BTW, I think the term "migrate" is highly appropriate here for the very same
reason that some others want to change it...

Last fall, Marshall Rose and I were among the participants in a panel
discussion on protocol standards at the NORDUNET conference in Stockholm.
Rolf Nordhagen, the Norwegian moderator, led off with a question that pretty
much said it all: "If OSI is the solution, then what is the problem?"

I sure wish I had thought of that one. But it's better that a European
said it first.

Phil
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 14:24:45 PDT (Tue)
From:      [email protected] (John Romkey)
To:        [email protected]
Cc:        [email protected]
Subject:   re: SLIP reliability
Dave Kell asks:
   Does SLIP have the same level of error detection and correction that
   ethernet-based IP has?

IP and its transport protocols (TCP or UDP or whatever) running over
SLIP will use the same error detection algorithms (IP header checksum,
TCP or UDP data checksum) that they will over ethernet.

SLIP doesn't include any error checking; it just frames the packet
over an asynchronous link. Ethernet does a CRC check of each packet,
so there is a difference at this level.
			- john romkey
USENET/UUCP: [email protected]	Internet: [email protected]
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 12:17:13 EDT
From:      [email protected]
To:        [email protected]
Subject:   TCPtrace port to HP
I have a colleague who needs to know the effort required to
port TCPtrace to an HP 3000.  I don't know if there's some
showstoppers in the kernel arrangement that would prevent
this from being easy.  I assume IP is similar enough to make 
that portion a wash.  Please write me directly.

	Walt Lazear
	[email protected]
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 14:33:20 EDT
From:      Bill Streilein <[email protected]>
To:        [email protected]
Subject:   bootp
Hello,
Does anyone know of a public domain bootp
source?  Maybe another public domain trivial
boot program?

Thanx in advance,
Bill Streilein
[email protected]
Wellfleet Communications, Inc.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 10:35:11 GMT
From:      ads.com!snmp-ok-forw%[email protected]  (Armin Schweizer)
To:        [email protected]
Subject:   SNMP Agents on SUN
As most of us know, SUN currently does not intend to deliver
SNMP agents with their SUN/3 and SPARC Systems. As I was
informed, there are SUN-SNMP agents available from the following
universities:

- Massachusets Institute of Technology
- Carnegie Mellon
- University of Tennessee, Knoxville

Who can tell me more specific (e-)mail addresses?

thank you
armin schweizer


-- 

       Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
                  4002 Basel / Switzerland
	          phone: -41-61-697'79'46
		  e-mail: [email protected]
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 14:54:46 EDT
From:      Bill Streilein <[email protected]>
To:        [email protected]
Subject:   Subnet Broadcasting
Hello,

Mogul & Postel [RFC 950] specify that the subnet field must
never be all 0's or all 1's.  Thus,

       128.10.0.0  with a mask of 255.255.255.0 

would be an invalid subnet.  Has the thought on this changed
since this was proposed?  For instance, if all broadcasts are
all 1's only, is a 'zero' subnet allowed? 

Thanx in advance,
Bill Streilein
[email protected]
Wellfleet Communications, Inc.
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 18:14:11 PDT (Tue)
From:      [email protected] (John Romkey)
To:        [email protected]
Cc:        [email protected]
Subject:   Subnet Broadcasting
There are a couple of reasons why all 0's is a bad idea. One is
historical reasons; old versions of the BSD code used to use all 0's
as the broadcast address.

Another reason is to help screen out bugs. An uninitialized value will
often default to 0, so from a technical perspective it's often a good
idea to avoid using 0 as a magic number, like a subnet number or such.
			- john romkey
USENET/UUCP: [email protected]	Internet: [email protected]
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 13:10:47 GMT
From:      [email protected]  (Peter da Silva)
To:        [email protected]
Subject:   Re: How about comp.internet?
In article <[email protected]> [email protected] (Curt Welch) writes:
> I agree that there is a real need for both a general Internet news group
> and a technical group.  However, I think the best solution would be
> to move all the non technical discussions to a new newsgroup, and let
> TCP-IP return to what it once was.

Hear, hear. I read c.p.tcp-ip for tcp-ip information. We don't have any
interest in the Internet or Internet politics... we use tcp-ip internally
along with tp4, and could care less about the politics.
-- 
`-_-' Peter da Silva. +1 713 274 5180.  <[email protected]>
 'U`  Have you hugged your wolf today?  <[email protected]>
@FIN  Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 14:58:00 GMT
From:      [email protected] (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET
Net 10 is a class A network number.  As we run out of network
numbers someone is going to need it, don't stick it in some
museum.  I'm sure that if anyone asked there would be lots
of volunteers who could turn in several class B network numbers...

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 16:42:25 GMT
From:      [email protected]  (Joe Schmo)
To:        [email protected]
Subject:   Re: Duplicate Internet address on same network
The culprit has been determined to be a Sun 4 running both TCP/IP and DECnet.
The DECnet software for the Sun is Sunlink DNI.  Only Intergraph machines pick
up this address translation error, Suns and HPs don.  We haven't determined 
whether its a Sun problem or Intergraph problem.  No offense, but Intergraphs
are weird when it comes to TCP/IP.



Steven W. Lodin  
Advanced Instrumentation Engineering
Delco Electronics Corp

AT&T:    (317) 451-8722    GM: 8-322-8722
Domain:  lodin%[email protected]
  or     [email protected]
  or     [email protected]
UUCP:    <backbone>!pur-ee!koiasvr01!lodin
GM:      LODIN, SW <KOESS::SWLODIN>
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 21:14:04 EDT
From:      [email protected]  (James B. Van Bokkelen)
To:        [email protected]  (Dave Kell)
Cc:        [email protected]
Subject:   Re: SLIP reliability
	Does SLIP have the same level of error detection and correction that
	ethernet-based IP has?

IP has header checksums, and they're the same wherever IP is run.
Likewise, the TCP checksum is mandatory.  UDP can optionally use the
same algorithm, but some vendors believe this costs too much speed,
so they omit them, regardless of the network media.  IP and UDP have no
"correction" in and of themselves, but TCP will do retransmits if the
checksum catches damage, or packets are lost altogether.

What Ethernet has that SLIP doesn't is a link-layer CRC-16, which can
do a pretty good job of detecting damage while on the cable.  SLIP
has no error detection at all at the link layer.  Of course, the
Ethernet CRC-16 may not detect packets damaged in the interface, or
in the host before transmission or after reception.  This sort of
undetected lower-layer damage happens much more often than the
optimistic crowd would like to believe, and is at the root of the
widely held belief that "end-to-end checksums are a Good Thing".

James B. VanBokkelen				FTP Software Inc.
[email protected]					617-246-0900
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 18:32:29 GMT
From:      [email protected]  (Jeff Makey)
To:        [email protected]
Subject:   Security fix for anonymous uucp (was: anonymous ftp, and the dangers thereof)
In article <[email protected]> [email protected] (Liudvikas Bukys) writes:
>1.  Here's one "minor problem" report: I have heard that .rhosts
>    files have been uucped into ~uucp.  Think about it.

I did think about it for a bit, and then I changed the following
/etc/passwd entry:

    uucp:*:66:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:

into:

    uucp:*:66:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/dev/null
    UUCP:*:66:1:UNIX-to-UNIX Copy:/usr/spool/uucp:

(order is important to preserve "ls -l" output) and changed all
occurrences of "su uucp" in my crontab file into "su UUCP".  This
maintains "~uucp" as a public place to put files, but "su uucp" fails
with a "No shell" error.  Any programs that have a legitimate need to
run with the uucp user id can get to it through the "UUCP" login name,
whose home directory is *not* world-writable.

Sorry for putting this on TCP-IP, but that's where it started.
Followups are directed to alt.security.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: [email protected]    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 23:21:35 EDT
From:      Mark Bodenstein <[email protected]>
To:        Joe Smith <[email protected]>
Cc:        [email protected]
Subject:   Re: Ancient articles re-appearing.
On 7 Jun 90 06:25:23 GMT you said:
>This article showed up on my system.  Any idea who's machine is in a time warp?
I've noticed this too (and I believe John Shriver said he also did.)  Wierd.

Here are the headers from two appearances of a message - the first April 21,
the second June 5.  (Someone here happened to be saving tcp-ip mailing list
messages from this period.)

Mark Bodenstein   ([email protected]; 607-255-8059)
Cornell University

-----------First appearance of the message:---------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 0144; Sat, 21
 Apr 90 14:58:04 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Sat, 21 Apr 90 14:58:01 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 21 Apr 90
 11:05:50 PDT
Received: by ucbvax.Berkeley.EDU (5.62/1.41)
        id AA07444; Sat, 21 Apr 90 10:57:57 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for [email protected] ([email protected])
        (contact [email protected] if you have questions)
Date: 21 Apr 90 17:50:57 GMT
From: [email protected]  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <[email protected]>
References: <[email protected]>, <[email protected]>,
 <[email protected]>
Sender: [email protected]
To: [email protected]

In article <[email protected]>
        [email protected] (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)

----------------Second appearance of the message:------------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 1172; Tue, 05
 Jun 90 20:30:44 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Tue, 05 Jun 90 20:30:24 EDT
Received: from ucbvax.Berkeley.EDU ([128.32.133.1]) by NIC.DDN.MIL with TCP;
 Mon, 4 Jun 90 12:53:02 PDT
Received: by ucbvax.Berkeley.EDU (5.63/1.41)
        id AA14464; Mon, 4 Jun 90 06:39:29 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for [email protected] ([email protected])
        (contact [email protected] if you have questions)
Date: 3 Jun 90 08:10:10 GMT
From: [email protected]  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <[email protected]>
References: <[email protected]>, <[email protected]>,
 <[email protected]>
Sender: [email protected]
To: [email protected]

In article <[email protected]>
        [email protected] (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 21:14:19 GMT
From:      [email protected] (rja7m)
To:        comp.protocols.tcp-ip
Subject:   Re: How about comp.internet?
Let's try  comp.NET.internet instead since
it is a safe bet that other networks (e.g. BITNET/EARN)
might later also want such a group and it
is more flexible...

Ran
[email protected]

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 00:05:36 GMT
From:      [email protected]  (John Dotts Hagan)
To:        [email protected]
Subject:   Re: TCP-IP Print Spooler
Does anyone have a version of Transcript that uses IP/TCP to open a connection
to a postscript device and then do the print thing?

The problem with most of the other mentioned methods is that they are one way
connections - that is, the connection is opened and data is dumped from the
host to the printer.  Some (maybe all) of them can deal with flow control by
not acking TCP frames, or such, but all the methods seem to not be able to read
data from the printer.

Postscript printers like to talk back (error messages, other stuff?) that lets
you know what is going on.

Anyone changed all the open's in the transcript package to be network
connections?

--Kid.
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 01:47:27 GMT
From:      [email protected]  (Jeffrey Mogul)
To:        [email protected]
Subject:   Re: Subnet Broadcasting
In article <[email protected]> [email protected] (Bill Streilein) writes:
>Mogul & Postel [RFC 950] specify that the subnet field must
>never be all 0's or all 1's.  Thus,
>
>       128.10.0.0  with a mask of 255.255.255.0 
>
>would be an invalid subnet.  Has the thought on this changed
>since this was proposed?  For instance, if all broadcasts are
>all 1's only, is a 'zero' subnet allowed? 

We recommended against "subnet number 0" because there is some
fear that certain software may use "0" internally to mean something
like "reserved" or "not yet set".  It seemed safer to ban the use
of this value for numbering a real subnet, to avoid any mysterious
bugs.

Also, I'm not sure everyone has stopped using all-zeros broadcasts.

In my experience, it is possible to get away with a subnet numbered
zero, but why tempt fate?

-Jeff
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 03:21:35 GMT
From:      [email protected] (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Ancient articles re-appearing.
On 7 Jun 90 06:25:23 GMT you said:
>This article showed up on my system.  Any idea who's machine is in a time warp?
I've noticed this too (and I believe John Shriver said he also did.)  Wierd.

Here are the headers from two appearances of a message - the first April 21,
the second June 5.  (Someone here happened to be saving tcp-ip mailing list
messages from this period.)

Mark Bodenstein   ([email protected]; 607-255-8059)
Cornell University

-----------First appearance of the message:---------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 0144; Sat, 21
 Apr 90 14:58:04 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Sat, 21 Apr 90 14:58:01 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 21 Apr 90
 11:05:50 PDT
Received: by ucbvax.Berkeley.EDU (5.62/1.41)
        id AA07444; Sat, 21 Apr 90 10:57:57 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for [email protected] ([email protected])
        (contact [email protected] if you have questions)
Date: 21 Apr 90 17:50:57 GMT
From: [email protected]  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <[email protected]>
References: <[email protected]>, <[email protected]>,
 <[email protected]>
Sender: [email protected]
To: [email protected]

In article <[email protected]>
        [email protected] (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)

----------------Second appearance of the message:------------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 1172; Tue, 05
 Jun 90 20:30:44 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Tue, 05 Jun 90 20:30:24 EDT
Received: from ucbvax.Berkeley.EDU ([128.32.133.1]) by NIC.DDN.MIL with TCP;
 Mon, 4 Jun 90 12:53:02 PDT
Received: by ucbvax.Berkeley.EDU (5.63/1.41)
        id AA14464; Mon, 4 Jun 90 06:39:29 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for [email protected] ([email protected])
        (contact [email protected] if you have questions)
Date: 3 Jun 90 08:10:10 GMT
From: [email protected]  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <[email protected]>
References: <[email protected]>, <[email protected]>,
 <[email protected]>
Sender: [email protected]
To: [email protected]

In article <[email protected]>
        [email protected] (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 11:10:26 PDT (Wed)
From:      [email protected] (John Romkey)
To:        [email protected]
Cc:        [email protected]
Subject:   IP Addresses (Subnets)
The dotted-decimal notation (128.38.253.44) is just a direct
representation of the 32 bit IP address. It doesn't (necessarily)
break apart neatly into net, subnet and host numbers at dot
boundaries. So the 3rd octet field in the dot notation is equivalent
to the third octet in the 32 bit number.
			- john romkey
USENET/UUCP: [email protected]	Internet: [email protected]
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 11:24:55 PDT
From:      [email protected] (Kwang Sung)
To:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]TC.NORTHROP.COM, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], mystie.rtp.dg.com!don%[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
du!nelson
    infmx!uunet!unx.dec.com!jjf infmx!uunet!uvcw.uvic.ca!eskovgaa infmx!uunet!voder!ucbvax!nrtc.northrop.com!Stef
    infmx!uunet!watcgl.waterloo.edu!aparghi infmx!uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike
    infmx!uunet!wrs!yuba!hwajin



			

Dear Mr. Bob Sutterfield:


	Now I would like to finalize my proposal on creation of a new
newsgroup "comp.protocols.iso.migration".

	Here is a list of all persons who have responded to my postings 
so far as of 11:00 PST, June 13, 1990. They voted with a serious mind. 
I've collected the info to make a decision for all of us.

	Obviously, majority wanted to create such a newsgroup on USENET.
Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection, I proposed such a 
newsgroup on USENET. I hope we can have always close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you create a new newsgroup "comp.protocols.iso.migration"
as soon as possible so that we can discuss seriously and aggressively,
and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
any more ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang


-------------------------------------------------------------------------------
Persons who have responded to my proposal so far:                    	Vote:
-------------------------------------------------------------------------------

uunet!YKTVMX.BITNET!YAKOV Tue Jun 12 08:15:38 1990			Yes
uunet!SPD.3Mail.3Com.COM!Allen_Rochkind					Yes
Amit Parghi <uunet!watcgl.waterloo.edu!aparghi>				No
[email protected] (Bob Sutterfield)					Yes
Bill Streilein <nsc!wellfleet.com!bstreile>				?
cire|eric <uunet!cisco.com!cire>					No
[email protected] (Cliff Frost {415} 642-5360)				?
[email protected] (Chris Perry)					Yes
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)				?
uunet!Eng.Sun.COM!dawei (David Yang)					Yes
uunet!East.Sun.COM!db (David Brownell)					No
[email protected] (Dennis Ferguson)				?
[email protected] (Einar Stefferud)				No
uunet!gateway.mitre.org!epg						Yes
Erik Skovgaard <uunet!uvcw.uvic.ca!eskovgaa>				Yes
James M Galvin <uunet!TIS.COM!galvin>					Yes
[email protected] (George Michaelson)				No
[email protected] (Fred R. Goldstein)			Yes
[email protected] (David Grieve)						Yes
uunet!wrs!yuba!hwajin (Hwa Jin Bae)					No
att!lzaz!jer								Yes
uunet!rlgvax.OPCR.ICL.COM!jessop (Lynn Jessop)				?
uunet!unx.dec.com!jjf (John J. Franey)					Yes
nsc!asylum.sf.ca.us!karl (Karl Auerbach)				No
[email protected] (Keith Brown)						No
uunet!gateway.mitre.org!kit						Yes
uunet!infmx!kwang (Kwang Sung)						Yes
Hakiml Laraqui  <uunet!sics.se!laraqui>					?
[email protected] (Louis A. Mamakos)				Yes
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
[email protected] (Marshall Rose)					No
Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>				No
[email protected]							Yes
uunet!gateway.mitre.org!patb (Pat Blankenship)				Yes
[email protected] (Phil Karn)					Yes
[email protected]							Yes
[email protected] (Gene Saunders)			Yes	
[email protected] ("Martin Lee Schoffstall")				Yes	
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>			Yes
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>	 	Yes	
[email protected] (Torben Nielsen)				No
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)			Yes
[email protected] (Amanda Walker)				No
[email protected] (Welch)						Yes
<uunet!bigfut.enet.dec.com!callon>					?
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy (Don Lehman)		No
"Doug McCallum" <nsc!ico.isc.com!dougm>                             	No
uunet!netwrx1!graham							Yes
uunet!mlb.semi.harris.com!jdr (Jim Ray)				 	No	
uunet!VitaM6!marciano (Marciano Pitargue)				Yes
JM Bennett <uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike>		Yes
nsc!cs.UMD.EDU!pete (Pete Cottrell)					Yes
nsc!gateway.mitre.org!reichlen						Yes

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 04:29:04 GMT
From:      [email protected]  (jaleel ihsan)
To:        [email protected]
Subject:   Re: Please not yet again
In article <[email protected]>, [email protected] (David J. Farber) writes:
> While I know it will not help to stop the religious wars, please take a peek at
> the report produced by the Board on telecommunications and Computer
> Applications of the National Research Council dated 1985 (work started
> in 1983) titled:
> 
> Transport Protocols for the DOD Data Networks -- report to the DoD and the NBS
> it compared TP/4 and TCP.
> 
> Dave

How can I get a copy, preferably electronic.

Jaleel
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 12:21:59 PDT
From:      [email protected] (Kwang Sung)
To:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
fmx!uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy,
        infmx!uunet!sacto.West.Sun.COM!sparc2!ts,
        infmx!uunet!salt.acc.com!lionel, infmx!uunet!sics.se!laraqui,
        infmx!uunet!sparta.com!harris, infmx!uunet!sun!bridge2!fjd,
        infmx!uunet!sun.soe.clarkson.edu!nelson, infmx!uunet!un

x.dec.com!jjf
    infmx!uunet!uvcw.uvic.ca!eskovgaa infmx!uunet!voder!ucbvax!nrtc.northrop.com!Stef
    infmx!uunet!watcgl.waterloo.edu!aparghi infmx!uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike
    infmx!uunet!wrs!yuba!hwajin kwang



			

Dear Mr. Bob Sutterfield:


	Now I would like to finalize my proposal on creation of a new
newsgroup "comp.protocols.iso.migration".

	Here is a list of all persons who have responded to my postings 
so far as of 11:00 PST, June 13, 1990. They voted with a serious mind. 
I've collected the info to make a decision for all of us.

	Obviously, majority wanted to create such a newsgroup on USENET.
Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection, I proposed such a 
newsgroup on USENET. I hope we can have always close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you create a new newsgroup "comp.protocols.iso.migration"
as soon as possible so that we can discuss seriously and aggressively,
and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
any more ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang


-------------------------------------------------------------------------------
Persons who have responded to my proposal so far:                    	Vote:
-------------------------------------------------------------------------------

uunet!YKTVMX.BITNET!YAKOV Tue Jun 12 08:15:38 1990			Yes
uunet!SPD.3Mail.3Com.COM!Allen_Rochkind					Yes
Amit Parghi <uunet!watcgl.waterloo.edu!aparghi>				No
[email protected] (Bob Sutterfield)					Yes
Bill Streilein <nsc!wellfleet.com!bstreile>				?
cire|eric <uunet!cisco.com!cire>					No
[email protected] (Cliff Frost {415} 642-5360)				?
[email protected] (Chris Perry)					Yes
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)				?
uunet!Eng.Sun.COM!dawei (David Yang)					Yes
uunet!East.Sun.COM!db (David Brownell)					No
[email protected] (Dennis Ferguson)				?
[email protected] (Einar Stefferud)				No
uunet!gateway.mitre.org!epg						Yes
Erik Skovgaard <uunet!uvcw.uvic.ca!eskovgaa>				Yes
James M Galvin <uunet!TIS.COM!galvin>					Yes
[email protected] (George Michaelson)				No
[email protected] (Fred R. Goldstein)			Yes
[email protected] (David Grieve)						Yes
uunet!wrs!yuba!hwajin (Hwa Jin Bae)					No
att!lzaz!jer								Yes
uunet!rlgvax.OPCR.ICL.COM!jessop (Lynn Jessop)				?
uunet!unx.dec.com!jjf (John J. Franey)					Yes
nsc!asylum.sf.ca.us!karl (Karl Auerbach)				No
[email protected] (Keith Brown)						No
uunet!gateway.mitre.org!kit						Yes
uunet!infmx!kwang (Kwang Sung)						Yes
Hakiml Laraqui  <uunet!sics.se!laraqui>					?
[email protected] (Louis A. Mamakos)				Yes
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
[email protected] (Marshall Rose)					No
Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>				No
[email protected]							Yes
uunet!gateway.mitre.org!patb (Pat Blankenship)				Yes
[email protected] (Phil Karn)					Yes
[email protected]							Yes
[email protected] (Gene Saunders)			Yes	
[email protected] ("Martin Lee Schoffstall")				Yes	
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>			Yes
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>	 	Yes	
[email protected] (Torben Nielsen)				No
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)			Yes
[email protected] (Amanda Walker)				No
[email protected] (Welch)						Yes
<uunet!bigfut.enet.dec.com!callon>					?
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy (Don Lehman)		No
"Doug McCallum" <nsc!ico.isc.com!dougm>                             	No
uunet!netwrx1!graham							Yes
uunet!mlb.semi.harris.com!jdr (Jim Ray)				 	No	
uunet!VitaM6!marciano (Marciano Pitargue)				Yes
JM Bennett <uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike>		Yes
nsc!cs.UMD.EDU!pete (Pete Cottrell)					Yes
nsc!gateway.mitre.org!reichlen						Yes

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 10:02:33 EDT
From:      "Don Garner (CADIG STAFF) " <[email protected]>
To:        [email protected] (Merton Campbell Crockett)
Cc:        [email protected], [email protected]
Subject:   Re:  Mourning of the passing of the ARPANET
Are there no comments on what it means to lose ARPANET?
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 10:50:06 EDT
From:      Jack Haverty <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
Perhaps instead of retiring #10 to a museum, we could have a ceremony
at Interop where the number is officially "retired", and a banner hoisted
to the ceiling - anybody volunteer to make a banner out of fishnet?
Then net 10 could be assigned to be used to create a bunch of class B
numbers for aspiring neonetworks who want to follow in the Arpanet's
footsteps (yes I know that's technically difficult).

Jack

Dan Lynch - are you listening....
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 15:28:32 -0400
From:      "Louis A. Mamakos" <[email protected]>
To:        [email protected] (Kwang Sung)
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], mystie.rtp.dg.com!don%[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
You seem to be confused.

When someone mentioned setting up a mailing list, they meant a discussion
group to talk about the topic you proposed.  It certainly does not mean a
list of people who happened to be fool enough to comment on your posting
in comp.protocols.tcpip.

This is not how a new newsgroup is created.  You should probably post a
note in news.group, and I'm sure someone will tell you what the proper 
procedure is.  Usually an announcement is made, discussion follows, and then
a call for votes is taken.  These votes are usually collected by some 
neutral party.  There's a good reason for that; for example you thought that
I was somehow in favor of such a newsgroup; I am NOT.

There are rules which determine what a "passing" vote for a newsgroup are.  I
believe that you need 100 more "YES" votes than "NO" votes.  I'm probably
wrong or mistaken.  If you really want to pursue this folly, I suggest that
you do it in the correct forum, which is most definately NOT the comp.protocols.
tcpip newsgroup/[email protected] mailing list. 

Again, for the record, I'm against a newsgroup.  Existing newsgroup should be
used to discuss this sort of thing unless the traffic is too heavy to bear or
wanders from the scope of the newsgroup.

louie
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 13:41:45 EDT
From:      Frank Kastenholz <kasten%[email protected]>
To:        [email protected], [email protected]
Subject:   Re:  IP Addresses (Subnets)
 > From [email protected] Wed Jun 13 13:08:44 1990
 > From: [email protected]  (The VolleyDog)
 > Organization: Naval Surface Warfare Center, Dahlgren VA
 > Subject: IP Addresses (Subnets)
 > Sender: [email protected]
 > To: [email protected]
 > 
 > I have a quick question, hopefully you will not flame to loudly with
 > regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 > how to specify a host when using a subnet.  In my particular instance we
 > have a class B network.  I am interested in how one would specify
 > addresses when a subnet of 6 bits is used.
 > 
 > Suppose I want the 300th host on the 1 subnet of a class B network with
 > a netmask of 255.255.252!  Should I specify the IP address as
 > 128.38.1.300 or 128.38.253.44
 > 
 > I guess my overall question is:  Should I specify the addressing using
 > the 3rd octet field in the dot notation as the subnet or as the 3rd
 > octet of the 32 bit field? 
Bob:

From RFC 1117 (Internet Numbers):
	
   One commonly used notation for internet host addresses divides the
   32-bit address into four 8-bit fields and specifies the value of each
   field as a decimal number with the fields separated by periods.  This
   is called the "dotted decimal" notation.  For example, the internet
   address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
   10.1.0.52.

So, the correct number is 128.38.253.44.

This is not an "official standard" but it is common usage to the degree that
no one does anything different.

Frank Kastenholz
Racal Interlan

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 13:48:47 EDT
From:      Doug Nelson <08071TCP%[email protected]>
To:        The VolleyDog, <[email protected]>, "TCP/IP list (plus more)" <[email protected]>
Subject:   Re: IP Addresses (Subnets)
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.
>
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44
>
>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field?

The best answer is "none of the above".  If your netmask is 255.255.252.0,
and you are on the first subnet of network 128.38, then your address range
begins with 128.38.0.0, and ends with 128.38.3.255 (the latter being your
subnet broadcast address).  So, if your first host was numbered 128.38.1.1,
then your 300th host would be 128.38.2.44.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 14:48:55 GMT
From:      [email protected]  (Fred R. Goldstein)
To:        [email protected]
Subject:   Re: SLIP reliability
In article <[email protected]>, [email protected] (James B. Van Bokkelen) writes...
>What Ethernet has that SLIP doesn't is a link-layer CRC-16, which can
>do a pretty good job of detecting damage while on the cable.  SLIP
>has no error detection at all at the link layer.  Of course, the
>Ethernet CRC-16 may not detect packets damaged in the interface, or
>in the host before transmission or after reception.  

Slight correction.  Ethernet, like 802.{3,4,5}, has a 32-bit CRC, not a 
16-bit CRC.  (BTW, "CRC-16" is the name of the bisync/DDCMP 16-bit 
checksum; "CRC-CCITT" is the 16-bit HDLC checksum.  CRC-32 is the 
LAN checksum, also optional in HDLC, and historically developed for 
Autodin-II.)

The 32-bit Ethernet checksum maintains a Hamming distance of 4 up to the 
maximum Ethernet packet, or for that matter up to about 12K bytes.  Thus 
ANY 3 bit errors will be caught, or any one error of under 32 bits.
A 16-bit CRC maintains a Hamming distance of 3 up to 4K bytes.  Exceed
that error limit and you're subject to a "crap shoot" of 2**n for n bits 
of CRC.  With 32 bits, that's a very low probability of undetected error 
no matter how you slice it.

The TCP and IP checksums are straight arithmetic.  Frog two 16-bit words 
and you've got an undetected error.  The right two-bit error combo will
be undetected.  It's a whole lot better than nothing, but not as good as 
the Fletcher checksum and that's not as good as the more computationally 
intensive CRC (which is usually done in hardware).

SLIP, with no checking whatsoever, is a bad joke.  PPP uses CRC-CCITT,
which is pretty good (for reasonable MTUs).  Ethernet is close to 
bulletproof, with regard to line noise induced error.  (Host error is, 
as the man said, another story.  TCP's checksum is mainly there to 
detect it.)
---
Fred R. Goldstein   [email protected] 
                 or [email protected]
                    voice:  +1 508 486 7388 
opinions are mine along; sharing requires permission
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 14:50:06 GMT
From:      [email protected] (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET
Perhaps instead of retiring #10 to a museum, we could have a ceremony
at Interop where the number is officially "retired", and a banner hoisted
to the ceiling - anybody volunteer to make a banner out of fishnet?
Then net 10 could be assigned to be used to create a bunch of class B
numbers for aspiring neonetworks who want to follow in the Arpanet's
footsteps (yes I know that's technically difficult).

Jack

Dan Lynch - are you listening....

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 14:51:53 GMT
From:      [email protected]  (The VolleyDog)
To:        [email protected]
Subject:   IP Addresses (Subnets)
I have a quick question, hopefully you will not flame to loudly with
regard to  viewing RFCs.  I looked through RFC 950 to try to determine
how to specify a host when using a subnet.  In my particular instance we
have a class B network.  I am interested in how one would specify
addresses when a subnet of 6 bits is used.

Suppose I want the 300th host on the 1 subnet of a class B network with
a netmask of 255.255.252!  Should I specify the IP address as
128.38.1.300 or 128.38.253.44

I guess my overall question is:  Should I specify the addressing using
the 3rd octet field in the dot notation as the subnet or as the 3rd
octet of the 32 bit field? 

Thanks,
  Bob Hott


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

Fullname:         Robert W. (Bob) Hott
Mailing Address:  Naval Surface Warfare Center
                  Networks Branch (Code E41)
                  Dahlgren, Virginia  22448
DDN Mail:         [email protected]
DDN Mail:         [email protected]
Telephone:        (703) 663 - 7745

"If man were not meant to play volleyball, why are there so many beaches?"
	 - Bob Hott -
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:14:32 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   Re: Vote for/against "comp.protocols.iso.migration"
Dear Mr. Bob Sutterfield:


	Now I would like to finalize my proposal on creation of a new
newsgroup "comp.protocols.iso.migration".

	Here is a list of all persons who have responded to my postings 
so far as of 11:00 PST, June 13, 1990. They voted with a serious mind. 
I've collected the info to make a decision for all of us.

	Obviously, majority wanted to create such a newsgroup on USENET.
Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection, I proposed such a 
newsgroup on USENET. I hope we can have always close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you create a new newsgroup "comp.protocols.iso.migration"
as soon as possible so that we can discuss seriously and aggressively,
and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
any more ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang


-------------------------------------------------------------------------------
Persons who have responded to my proposal so far:                    	Vote:
-------------------------------------------------------------------------------

uunet!YKTVMX.BITNET!YAKOV Tue Jun 12 08:15:38 1990			Yes
uunet!SPD.3Mail.3Com.COM!Allen_Rochkind					Yes
Amit Parghi <uunet!watcgl.waterloo.edu!aparghi>				No
[email protected] (Bob Sutterfield)					Yes
Bill Streilein <nsc!wellfleet.com!bstreile>				?
cire|eric <uunet!cisco.com!cire>					No
[email protected] (Cliff Frost {415} 642-5360)				?
[email protected] (Chris Perry)					Yes
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)				?
uunet!Eng.Sun.COM!dawei (David Yang)					Yes
uunet!East.Sun.COM!db (David Brownell)					No
[email protected] (Dennis Ferguson)				?
[email protected] (Einar Stefferud)				No
uunet!gateway.mitre.org!epg						Yes
Erik Skovgaard <uunet!uvcw.uvic.ca!eskovgaa>				Yes
James M Galvin <uunet!TIS.COM!galvin>					Yes
[email protected] (George Michaelson)				No
[email protected] (Fred R. Goldstein)			Yes
[email protected] (David Grieve)						Yes
uunet!wrs!yuba!hwajin (Hwa Jin Bae)					No
att!lzaz!jer								Yes
uunet!rlgvax.OPCR.ICL.COM!jessop (Lynn Jessop)				?
uunet!unx.dec.com!jjf (John J. Franey)					Yes
nsc!asylum.sf.ca.us!karl (Karl Auerbach)				No
[email protected] (Keith Brown)						No
uunet!gateway.mitre.org!kit						Yes
uunet!infmx!kwang (Kwang Sung)						Yes
Hakiml Laraqui  <uunet!sics.se!laraqui>					?
[email protected] (Louis A. Mamakos)				Yes
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
[email protected] (Marshall Rose)					No
Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>				No
[email protected]							Yes
uunet!gateway.mitre.org!patb (Pat Blankenship)				Yes
[email protected] (Phil Karn)					Yes
[email protected]							Yes
[email protected] (Gene Saunders)			Yes	
[email protected] ("Martin Lee Schoffstall")				Yes	
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>			Yes
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>	 	Yes	
[email protected] (Torben Nielsen)				No
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)			Yes
[email protected] (Amanda Walker)				No
[email protected] (Welch)						Yes
<uunet!bigfut.enet.dec.com!callon>					?
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy (Don Lehman)		No
"Doug McCallum" <nsc!ico.isc.com!dougm>                             	No
uunet!netwrx1!graham							Yes
uunet!mlb.semi.harris.com!jdr (Jim Ray)				 	No	
uunet!VitaM6!marciano (Marciano Pitargue)				Yes
JM Bennett <uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike>		Yes
nsc!cs.UMD.EDU!pete (Pete Cottrell)					Yes
nsc!gateway.mitre.org!reichlen						Yes

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:15:36 GMT
From:      [email protected]  (Rick Jones)
To:        [email protected]
Subject:   Re: TCPtrace port to HP
>I have a colleague who needs to know the effort required to
>port TCPtrace to an HP 3000.  I don't know if there's some
>...
>	Walt Lazear
>	[email protected]
>----------

Did you say 3000 ??? Or did you really mean 9000? The 3000 runs one of
two versions of the MPE OS (MPE/V for the 'classic' h/w and MPE/XL for
the 'spectrum' (new whizzy risc ;-) h/w. It's TCP/IP is an in-house
implementation that does not look at all like standard BSD TCP/IP. It
also uses NetIPC and not BSD sockets, so the interface to the
transport layer is not the same... It's the 9000 that runs the BSD
bits... 

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | (;place deprication here;)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:26:15 GMT
From:      [email protected]  (Jose Diaz-Gonzalez)
To:        [email protected]
Subject:   Re: SLIP reliability
In article <[email protected]> golds[email protected] (Fred R. Goldstein) writes:
>
>SLIP, with no checking whatsoever, is a bad joke.  PPP uses CRC-CCITT,
>which is pretty good (for reasonable MTUs).  Ethernet is close to 

Could some one explain what PPP is, or where can I find more info about
it?  Thanks.

	-- Jose


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+				     +					+
+	Jose Pedro Diaz-Gonzalez     +		                    	+
+	SrMTS			     +					+
+	GTE Laboratories, Inc.       +	   Tel:   (617) 466-2584	+
+	MS-46                 	     +	   email: [email protected]    	+
+	40 Sylvan Rd.		     +					+
+	Waltham, MA 02254	     +					+
+				     +					+
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:29:26 GMT
From:      [email protected]  (howie)
To:        [email protected]
Subject:   Question About Gateway Machines
Here's something that I've wondered about:

How does a gateway machine know which ethernet connection to use?


I understand there could be times that you would want to broadcast through 
both ethernet connections.  But aren't there times you just want to send
data out of one connection, leaving the other one alone?  

Where can I find documentation on this?  Most of anything I've read, deals 
with single-homed systems.

					
				      thanks,

-- 
				       howie              

				       uw-beaver!ssc-vax!voodoo!howie 
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:58:00 GMT
From:      [email protected] (Michael Crawford)
To:        comp.protocols.tcp-ip
Subject:   Re:  Growing sentiment against gateways

In article <[email protected]> [email protected] writes:
>
>Most, if not all, of the regional networks attached to the NSFnet backbone
>have appropriate usage guidelines.  Traffic which is solely for commercial
>purposes is prohibited from traversing the NSFNet backbone--there are most
>definitely rules which govern Internet access.  However, in the case of

I am curious how a commercial UUCP site would post to misc.jobs.offered,
and guarantee that their ad did not traverse the backbone.  Suppose
their upstream site was on UUCP, and so on for a few hops, and all these
commercial companies provide each other UUCP for commercial purposes.

It seems to me that it is absurd for a company to have to consider what
political requirements a distant network layer might have when posting
to the news.

Or consider this: suppose a company has a network that links itself and
its clients.  Suppose the company and the client each have an internet
connection, but the shortest-hop is to go over the internal network.

It is perfectly legitimate in this case that the company should bill its
client via SMTP mail.

Suppose the regional or the NSF backbone now installed a router that made the
hop count from accounts receivable to the client's account payable office
shorter than the hop count on the internal network.  Current protocols
will shortly send all the bills over the NSF backbone.

I am not advocating that the NSF or the regionals should provide free
communications services to companies, but really, there should be some
realistic thought on this.

Perhaps one could set a bit in the IP header that says this packet is
not "Used Appropriately", and NSF routers could drop such packets.  (Just
kidding).  What would be more reasonable is for the companies to pay
for the usage they actually incur on the net, in some manner that is
simple and manageable.

-- 
Michael D. Crawford
Oddball Enterprises		Consulting for Apple Computer Inc.
606 Modesto Avenue		[email protected]
Santa Cruz, CA 95060		Applelink: [email protected]@INTERNET#
[email protected]	The opinions expressed here are solely my own.

		alias make '/bin/make & rn'

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 19:05:43 GMT
From:      [email protected]u
To:        [email protected]
Subject:   <None>
In article <[email protected]>, [email protected] (Fred R.
Goldstein) writes a bit about DECnet/OSI  Phase V in response to a previous
posting from John Franey (also of Digital)

Franey> DEC has commited itself to OSI.  All of its customers computer 
Franey> network nodes are going to be converted to OSI with the release of 
Franey> DECnet Phase V.  I work for DEC but not in communications engineering 
Franey> but please don't think this is a plug.  
 
Goldstein> While I'm not a spokesman, I do work for DEC in communications 
Goldstein> engineering.  We have certainly taken a leading role in OSI.  But 
Goldstein> we are also building TCP/IP.  And while Phase V is OSI up to Layer 
Goldstein> 3 it supports OSI and non-OSI in parallel using a "towers" approach. 
Goldstein> Most DEC-DEC applications won't use the OSI upper layers.  Note that
Goldstein> it's the upper layers of OSI that are most controversial.

DEC is making a significant change in direction, or at least agreeing to the
option of using a fairly length detour.  

DEC made a number of announcements at the New Orleans DECUS Symposium (early
May) that indicated that TCP/IP will play a very strong role in Phase V.  
As a starter, _all_ of the DECnet Phase V routers will be multiprotocol
routers, supporting DECnet Phase IV, OSI (DECnet Phase V) *and* IP.  

Given the Phase V architectural support for protocol towers in the DNS, I
would expect (hope for?) support of towers based on a TCP/IP stack.  Fred, 
is that what will happen?
-- 
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830              
[email protected]  or ...!{uupsi,uunet}!camb.com!bob      
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 21:07:54 GMT
From:      [email protected]  (Edward Levinson)
To:        [email protected]
Subject:   WIN/OSI phases
In UNIX Today!, June 11, 1990, on pg. 38 an article entitled "Net Tools
Ease Move From TCP/IP To OSI" appears about The Wollongong Group's OSI
product, WIN/OSI.

The following statement sounded strange to me.  Can anyone shed some
light on what Wollongong really means.

	"Wollongong recommends a four-part strategy for migration to
	OSI, starting with modifications to lower-level TCP/IP
	communications.  Phase 2 allows OSI applications to run over
	TCP/IP lower-level protocols.  Phase 3 introduces the TSB
	gateway from TCP/IP to OSI.  And, finally, full OSI compliance
	occurs in Phase 4."

Except for Phase 1 this sounds like ISODE.  Is this really a
productized ISODE?  What does the first phase mean?  (Could it be
adding RFC1066 code?)  Earlier in the story a "mixed stack" is
referred to, again implying ISODE.

The next paragraph is stranger.  It says that there is a SNMP agent
that "allows OSI devices to access Internet SNMP stations."  This
suggests to me that TWG has an SNMP agent on top of an OSI stack.  At
$200 sounds too good to be true.   Can anyone shed some light here?

Mostly it sounds like a garbled press release.  Garbled when it got
close to the real technical issues.

Thanks.../Ed

Edward Levinson                         Disclaimer:  The opinions expressed
levinson%[email protected]       here are my own and not that of
                                        Accurate Information Systems Inc.

Accurate Information Systems Inc.
3000 Hadley Road
South Plainfield, NJ  07080
(201) 754-7714
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 21:34:00 GMT
From:      [email protected]  (Steve Jay)
To:        [email protected]
Subject:   Multi-homed hosts and parallel networks
Fast networks (FDDI or UltraNet) are being installed in parallel with
existing ethernet networks.  Hosts are becoming multi-homed (more than
one IP address) for reasons other than IP routing.  Have there been any
discussions on how IP can cope with multi-homed hosts and (semi-)parallel
networks, such that traffic automatically takes the "best" path between
hosts?

Consider the following combination of networks and hosts.  Network 1 is
ethernet, Network 2 is something much faster.  Hosts B and C are connected
to both networks, host A is on network 1 only, and host D is on 2 only.

                         1                        2

        +-------+        |                        |
	|       |	 |                        |
	|   A   +--------+                        |
	|       |	 |       +------+         |
        +-------+        |       |      |         |
			 +-------+  B   +---------+
			 |       |      |         |
                         |       +------+         |
	         	 |       +------+         |
                         |       |      |         |
			 +-------+  C   +---------+
			 |       |      |         |        +------+
                         |       +------+         |        |      |
			 |                        +--------+   D  |
                         |                        |        |      |
			 |                        |        +------+


How can it be arranged so that IP traffic between any two hosts travels
over the "best" path?

I put "best" in quotes for a reason.  It may be considered better to have
some traffic between B & C go over the ethernet rather than the faster
network.  You may not want to clog up the fast network with the tiny
packets generated by rlogin, but ftp data connections should be on the
fast network.

One of the reasons that this isn't easy is that names and IP addresses
refer to specific interfaces, not hosts.  In the above configuration,
host A has one interface (call it A-1), host B whas B-1 and B-2, host C
has C-1 and C-2, and host D has D-2.  Normally, in this situation, the
system administrator would alias the name B to B-1 or B-2 in /etc/hosts
(or equivalent). This leads to very inefficient routing.  If B is aliased
to B-2, then IP traffic between A and B could end up routing through host
C, rather than using the direct A-1 <-> B-1 path.  If B is aliased to B-1,
traffic between D and B could go through C.

The issue is not how to route an IP packet once an IP addresse has been
selected.  The issue is, how to decide what interface (and which network)
to use when there is more than one choice.  It's possible that the "best"
choice will vary during the life of one connection, based on packet sizes
and network loading.

I'm not looking for "clever" ways to assign names to IP addresses.  I'm
looking for ideas which might challenge some of the basic IP concepts,
like names being associated with interfaces instead of hosts, and routing
decisions based on a name specified by the user/application.  Have these
issues already been discussed anywhere?  A quick look at the RFC index
didn't help me.
 
I'm looking forward to benefiting from the accumulated wisdom on the net.
Thanks in advance.

Steve Jay
[email protected]  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"
 
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 23:21:24 GMT
From:      weintrau%[email protected]  (Weintraub, B. L.)
To:        [email protected]
Subject:   Help with Non-Homogeneous LAN?
We are in the process of planning a non-homogeneous LAN.  We are an engineering
group, and only a couple of us are reasonably computer-literate.  Nobody really
knows how to connect all of these machines.  For that matter, none of the 
computer experts around here have ever constructed such a diverse LAN either.  
So, please excuse any misuse of terminology in this posting.            

Here is a list of computers to be included:
1)  Several Hewlett-Packard 9000 series 300 workstations.  These belong to the
design/drafting section and are used primarily for CAD.
2)  One DEC VAXstation 3100.  Primary use is in running finite element codes. 
3)  Many varieties of Apple Macintosh.  
4)  IBM AT's running MS-DOS.
5)  IBM PS/2's running MS-DOS.
6)  IBM PS/2's running OS/2.

We wish file transfer capability between all of the above, as well as output
spooling to the following devices:
1)  HP plotter connected to HP workstation.
2)  HP plotter on DECserver.
3)  HP plotter on Localtalk. (Is this possible?)
4)  Apple Laserwriters, currently on Appletalk.
5)  Various HP printers, either connected to the HP workstations, or ?
6)  Possibly a DEC LN03 connected via a DECserver to a DECnet network.

We are also considering using one of the HP workstations or the VAXstation as a
fileserver.  Currently, the VAXstation is connected via DECnet over ethernet
to a site-wide network of numerous other VAXes.  The HP workstations are also
on the ethernet backbone.  We have a site license for Multinet which has not
been installed on the VAXstation yet.  It's a reasonable assumption that the
protocol-of-choice is TCP/IP, but please feel free to disagree.

Some of the options being considered are:
1)  Leave the Mac's on Appletalk and install a gateway Appletalk <--> Ethernet. 
Use some version of TCP/IP to talk to the HP's and IBM's, and either TCP/IP 
or Alisatalk or LANworks (when it's released) to talk to the VAX(es).  Or 
install ethernet cards in the Mac's.  Any comments on how well either option 
will work?  Any other suggestions?  
2)  Put the IBM's on Appletalk, or install Ethernet cards.  We tested Apple's
"Localtalk for MS-DOS", and it was less than satisfactory.  Evidently,
character formatting is lost in printing on a laserwriter.  Perhaps, there's
some patch that we did not discover.  Besides, are there equivalent cards for 
PS/2's?  Again, any comments or suggestions?
3)  What's the best way of accessing the plotters?  The most critical use for
the plotters is for the design/drafting section.  However, we'd like to access
them from other computers as well. We've been told to set up a "Block-mode 
Terminal", and use one of the HP workstations as a fileserver and print spooler.
Will this work?  Can other machines besides the HP's reach the plotters in this
configuration?  How about putting it on localtalk?  I've heard that there's a 
piece of hardware for this purpose.  Or, would it be best to connect them 
directly off the ethernet through a DECserver?
4)  We think that the connections VAXstation <--> HP workstation are pretty
obvious.  Anyone have experience with this one?

Does anybody know _specifically_ which hardware and software to use?  Has 
anyone ever done this?  Obviously, compatibility between various parts is a 
consideration as transparency of the completed network.  

Please e-mail or telephone.
Much thanks.

Barbara Weintraub
MP-8:  Accelerator Engineering and Maintenance
Los Alamos National Lab
(505)667-9742
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 00:50:16 GMT
From:      swrinde!zaphod.mps.ohio-sta[email protected]ucsd.edu  (Vance Morrison)
To:        [email protected]
Subject:   PCroute 2.1 release out
Hello,

PCroute2.1 is now available via anonymous FTP from accvuax.nwu.edu
(129.105.49.1).   This version is not too different from version 2.0.
The only differences are

	1) a BUG fix for the slip code.  If you are running SLIP,
   	   you should get the update.  The bug causes PCroute to hang
	   under high load.  The main reason for this this release is 
	   to get this bug fix out.

	2) Slight changes to the WD8003e driver that should allow
	   the router to work with some of the more recient western
	   digital cards (WD8013EBT and the WD8003EBT).   I have
	   no way of testing if these cards will work (since I 
	   don't have them).  I also have not written the changes
	   into the documentation.  If however, you do have one of
	   these cards and would like to beta-test this aspect of
	   the code, please contact me.  

If all goes well, a 'real' release will happen soon,  which should
feature (slow) packet driver support and true support for the expanded
buffer and 16 bit cards.  This release is really only to get the SLIP 
bug fix out.  

Vance
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 09:05:45 PDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   Re: PPP Info (was SLIP reliability)
Jose Diaz-Gonzalez:

For info on PPP see RFC-1134.

--jon.
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 02:15:22 GMT
From:      [email protected]  (Karl Auerbach)
To:        [email protected]
Subject:   Re: Efficiency (or lack thereof) of ASN.1.
In article <[email protected]> [email protected] (Christian Huitema) writes:
>A few comment on the efficiency of ASN.1. We did quite a lot of work on
>that at INRIA

>* the handling of the strings is comparable to what can be found in
>other syntaxes: the coding of the tag and length field may take 20
>instructions instead of 1 or 2, but it is outweighted by the copying of
>the string itself, which is syntax independant. The decoding can however
>be made much longer if your partner insists on passing its strings as
>``sequences of segments''.

I've found that constructorization of strings can add substaintially
to the overhead of the decoder.  Have you considered this in your numbers?

Thanks for your comments.

				--karl--
-----------[000269][next][prev][last][first]----------------------------------------------------
From:      [email protected]
To:        Kwang Sung <[email protected]>
Cc:        [email protected]
Subject:   
Kwang--

I'm tired!

And annoyed!!

Please, please, please, before we waste further bandwidth on this, look at the 
article "How to Create a New Newsgroup" in comp.announce.newusers.  This item, 
which you seem to be completely unaware of, describes the ESTABLISHED and 
LONG-STANDING procedure for creating a new newsgroup.

You haven't made even a minimal effort to a] determine what the proper 
procedure is or b] follow it.  You haven't posted a call for discussion, you 
haven't allowed anything remotely like a reasonable discussion peroiod, you 
haven't taken a proper vote or allowed the time for one; in short, you haven't 
made any attempt at all to do this in a "by the book" fashion.

Regardless of the merit (or lack thereof) of your proposal, the net effect of 
this is that we have to wade through a lot of extraneous nonsense in your 
(possibly misguided) quest to not 'bother either "comp.protocols.iso" or 
"comp.protocols.tcp-ip"any more'.

PLEASE!  READ THE PROCEDURE!  FOLLOW IT!  We've only been doing this on the 
Net for several years now.  And please, try to refrain from clogging this 
mailing list up with much nore of this.  There is an appropriate forum for 
this discussion, AND THIS MAILING LIST IS _NOT_ IT!!

|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
|           David N. Schlesinger || "When I have nothing to say,       |
|           The Wollongong Group ||  my lips are sealed;               |
| Internet: [email protected]        ||  say something once,               |
| POTS:     415/962-7219         ||  why say it again?" -- David Byrne |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|

-----------[000270][next][prev][last][first]----------------------------------------------------
From:      [email protected]
To:        "Don Garner (CADIG STAFF) " <[email protected]>
Cc:        [email protected]
Subject:   Re:   Re:  Mourning of the passing of the ARPANET
In <[email protected]>, "Don Garner (CADIG STAFF) 
" <[email protected]> writes:

> Are there no comments on what it means to lose ARPANET?


"Live in the future; it starting now."

|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
|           David N. Schlesinger || "When I have nothing to say,       |
|           The Wollongong Group ||  my lips are sealed;               |
| Internet: [email protected]        ||  say something once,               |
| POTS:     415/962-7219         ||  why say it again?" -- David Byrne |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 08:39:45 EDT
From:      [email protected] (Michael E. Pare)
To:        [email protected], [email protected]
Subject:   Re:  IP Addresses (Subnets)
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.

>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field? 

>Thanks,
>  Bob Hott

The first subnet using 6 bits will be 4.  Decimal 300 in binary is
100101100. The rightmost 8 bits belongs to the first field and is 44.
The leftmost 1 is part of the next field.  The resulting binary format
for the first two fields will be :

			00000101 00101100
			------
			subnet|---------|
				host
The resulting decimal values are 5 and 44 respectively.  Thus the IP address
will be 128.38.5.44 for the 300th host of the first subnet.
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu 14 Jun 90 09:45:44-CDT
From:      Matt Jonson <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected], [email protected], [email protected]
Subject:   Re: IP Addresses (Subnets)
Bob Hott <[email protected]> writes:
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field?


The dot decimal notation must break apart into octets, so there is no way
to go over 255 in any given piece.  So, depending on what you mean by
"the 1 subnet", it should look something like this:

     128.38. <6 subnet bits> <2 host bits> . <8 host bits>

host 1,300:            (1)  (256) + (32)+(8)+(4)
     128.38. <0 0 0 0 0 1> <0 1>. <0 0 1 0 1 1 0 0>
			4  +  1       32 + 8+4
  =  128.38.5.44
which is the 300th host on subnet 1, and is on a subnet whose first host is
128.38.4.1, and whose last host (the 1022nd) is 128.38.7.254.  You must
bear in mind that all ones and all zeros in the host portion is reserved.
I think your first subnet would actually be subnet 0, extending from
128.38.0.1 to 128.38.3.254.

Note your netMASK is still 128.38.252.0.  The netmask is only used for
the purpose of masking off the net portion of an ip address, because a logical
AND is performed on the netmask and any given host address (so the zeros knock
off the host number, and the ones pass just the net number) when you're
trying to determine a route for a particular packet. It looks like you got a
little confused on how your netmask relates to your address.

Hope I've been helpful,
MWJ
-------
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 08:47:23 EDT
From:      Frank Kastenholz <kasten%[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
 > From [email protected] Thu Jun 14 08:37:24 1990
 > From: Jack Haverty <[email protected]>
 > Subject: Re: Mourning of the passing of the ARPANET
 > To: [email protected]
 > Cc: [email protected], [email protected]
 > Mail-System-Version: <[email protected]>
 > 
 > Perhaps instead of retiring #10 to a museum, we could have a ceremony
 > at Interop where the number is officially "retired", and a banner hoisted
 > to the ceiling - anybody volunteer to make a banner out of fishnet?
 > Then net 10 could be assigned to be used to create a bunch of class B
 > numbers for aspiring neonetworks who want to follow in the Arpanet's
 > footsteps (yes I know that's technically difficult).
 > 
 > Jack
 > 
 > Dan Lynch - are you listening....
 > 

How about officially assigning NET 10 to Interop - then it could be brought out
of retirement each year for all of the newcomers to look at - sort of like
the IMP last year. Maybe during the "off season" Interop could keep 2 PC's
running in a backroom on some Ethernet, pinging each other - on NET 10.

Frank Kastenholz
Racal Interlan
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 09:05:38 EDT
From:      [email protected]  (James B. Van Bokkelen)
To:        [email protected]  (Fred R. Goldstein)
Cc:        [email protected]
Subject:   Re: SLIP reliability
Normally I know better than to say CRC-16, but...  Sorry.

In my personal experience (which includes supporting a lot of TCP/IP
nodes), I have only had one report of undetected data corruption in
TCP (a transposition caused by a device driver bug while transferring
a very repetitive raster file).  The combination of TCP and IP on
SLIP seems fairly robust in practice: For two years our Internet link
was leased-line SLIP, and I am using dial-up SLIP to send this, and
I've never seen an error that got past the checksum.  This may be
because there is a good match between the errors asynch lines tend to
generate and those the checksum is likely to detect.

James B. VanBokkelen				FTP Software Inc.
[email protected]					617-246-0900
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 11:56:12 -0400
From:      Hans-Werner Braun <[email protected]>
To:        [email protected], [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
>Oh, come now. Nobody's big enough to need a class A network. Entities
>that have class A networks now didn't get them because they've got big
>networks; they got them for political reasons. MIT and Stanford were
>big with DARPA. MERIT runs NSFNET. It'll be a long, long time before
>anyone with a class A net manages to accumulate sixteen million hosts.

Your comment is misleading. Merit had a class A network number long
before we had to do with NSFNET. The NSFNET backbone itself uses a Class B
network number. The reason why Merit has a network number was exclusively
on grounds of mapping addresses to the probably 200 or so packet switching
nodes that Merit had in that state of Michigan at that time (now much
more than 200). Potentially all those nodes map to what Merit calls
"hosts" and those (several different) hosts can map to many "ports."
Took Jon Postel and me quite a while to "fight" this out at that time.
It was not possible to fit this into a Class B space.
	
	-- Hans-Werner
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 13:06:23 -0400
From:      Stephen Wolff <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
> Oh, come now. Nobody's big enough to need a class A network. Entities
> that have class A networks now didn't get them because they've got big
> networks; they got them for political reasons. MIT and Stanford were
> big with DARPA. MERIT runs NSFNET.

Merit had net 35 a long time before there was an NSFNET.  Don't forget that
the Merit Computer Network grew up contemporaneously with the ARPANET - and
seems likely to outlast it by some time.  -s
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 08:22:36 GMT
From:      [email protected]  (Bill Wisner)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
[email protected] (Michael Stein) writes:

>Net 10 is a class A network number.  As we run out of network
>numbers someone is going to need it, don't stick it in some
>museum.

Oh, come now. Nobody's big enough to need a class A network. Entities
that have class A networks now didn't get them because they've got big
networks; they got them for political reasons. MIT and Stanford were
big with DARPA. MERIT runs NSFNET. It'll be a long, long time before
anyone with a class A net manages to accumulate sixteen million hosts.

Bill Wisner <[email protected]> Gryphon Gang Fairbanks AK 99775
Any member introducing a dog into the Society's premises shall be liable to
a fine of one pound. Any animal leading a blind person shall be deemed to be
a cat. -- Rule 46, Oxford Union Society, London
-----------[000278][next][prev][last][first]----------------------------------------------------
From:      [email protected]
To:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]et.dec.com, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Cc:        Kwang Sung <[email protected]>
Subject:   Creation of new NewsGroup
I would like to propose the creation of a new newsgroup.

                   "alt.flame.kwang"

KWANG!

READ THE PROCEDURE!

IT'S IN news.announce.newusers!

IT'S CALLED "HOW TO CREATE A NEW NEWSGROUP"!

IT TELLS YOU HOW TO CREATE A NEW NEWSGROUP!

THAT'S WHY IT'S CALLED THAT!

READ IT!

NOW!!

PLEASE!!!

CAN YOU HEAR ME, KWANG??

|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
|           David N. Schlesinger || "When I have nothing to say,       |
|           The Wollongong Group ||  my lips are sealed;               |
| Internet: [email protected]        ||  say something once,               |
| POTS:     415/962-7219         ||  why say it again?" -- David Byrne |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 15:07:00 CST
From:      "Dan Kellen" <[email protected]>
To:        "tcp-ip" <[email protected]>
Subject:   Thanks: I need help with subnetting
   Thanks to all the people that sent help or solutions to my problem.
   I was trying to set up the first subnet on a class B network, without 
   converting the whole network.  We have been assigning addresses as if 
   we were subnetted; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   Here's the solution I implemented.  

   I have configured both interfaces on the subnet gateway and all subnet
   machines on the subnet with class C netmask's and broadcast addresses.
   Meanwhile all other hosts on the network still have their class B netmask.
   I consider this a temporary configuration.

   Getting routing to work was my biggest problem.  Here's what I've done.

   On the subnet machines, I added a default route pointing to the 
   subnet gateway. 
       route add default 129.61.9.2 1

   On the subnet gateway, I added a default route pointing to the main 
   network with a metric of zero. 
       route add default 129.61.2.40 0

   On main network machines that want to talk to the subnet machines I have 
   had to add host routes.  I could not get dynamic routing to do this.
       route add 129.61.9.4 129.61.2.40 1

   Since that time, I have changed my main network gateways to announce a 
   default route via RIP.  I probably should have done this sooner, but we 
   are still moving from static routes to RIP.  I won't have to add the 
   default routes on the next subnet.
   
   I have been watching for broadcast storms, and have seen none.  But, when 
   the subnet gateway RIP's to the subnet 2 broadcast, other RIPers send it 
   a redirect.

   Here's how it looks.

  network: 129.61.0.0       network: 129.61.2.0         network: 129.61.9.0
  netmask: 255.255.0.0      netmask: 255.255.255.0      netmask: 255.255.255.0

                            this int. only             +-----+
                                |                      |     |
                    /\          \/               +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Dan
   ------------------------------------------------------------------
   Digital Equipment Corp.    Internet:  [email protected]
                              EASYnet:   ODIXIE::KELLEN
   System/Network Manager     Internet:  [email protected]
   Eglin AFB, Florida         PHONEnet:  (904)882-5498

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 16:39:59 EDT
From:      Rafat Y. Shaheen <[email protected]>
To:        [email protected], [email protected]
Subject:   Subnet Addressing
Robert W. (Bob) Hott writes:
 > 
 > I have a quick question, hopefully you will not flame to loudly with
 > regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 > how to specify a host when using a subnet.  In my particular instance we
 > have a class B network.  I am interested in how one would specify
 > addresses when a subnet of 6 bits is used.
 > 
 > Suppose I want the 300th host on the 1 subnet of a class B network with
 > a netmask of 255.255.252!  Should I specify the IP address as
 > 128.38.1.300 or 128.38.253.44
 > 
 > I guess my overall question is:  Should I specify the addressing using
 > the 3rd octet field in the dot notation as the subnet or as the 3rd
 > octet of the 32 bit field? 
Bob:

With all the ansewrs I have' read so far, only one answer looks allright:
It was from Michael.E.Pare [email protected]
The following is to confirm:

To get things straight now:

You want to have 6 bits for a subnet:

Your mask is : 255.255.252.0
And you can address up to 2**6 = 63 physical network
And up to 2**10 = 1023 hosts within one such network.

You declared the first 6 bits of the third octet to be the physical nets:

	11111111|11111111|11111100|00000000	<---- Subnet Mask
The first subnet will be to set the first bit in the physical net address,
which is the third position from the right in the third octet, that is:
	10000000|00100110|00000100|00000001
This correspond to:
	128.38.4.1 	<-----For the 1st host in the 1st subnet.
and for the 300th host:
	10000000|00100110|00000101|00101100
Which corresponds to:
	128.38.5.44 	<---- Same answer as Michael

Another example, for the second subnet and the 300th host:

	10000000|00100110|00001001|00101100
Which corresponds to:
	128.38.9.44

References:
[1] InterNetworking with TCP/IP, Douglas Comer (Purdu University),1988
RFCs:

The standard for subnet addressing comes from Mogul[RFC 950];
Clark [RFC 932], Karels [RFC 936], Gads [RFC 940], and Mogul[RFC 917]

All contain early proposals for subnet addressing schemes. Mogul[RFC 932] 
discusses broadcasting in the presence of subnets. Postel [RFC 925] 
considers the use of proxy ARP for subnets. Carl-Mitchell and
Quarterman [RFC 1027] discusses using proxy ARP to implement transparent
subnet gateways.

Best Regards.		

	... Shaheen

Old Dominion University (ODU)
Rafat Y. Shaheen
[email protected]

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 16:53:25 EDT
From:      Bob Stewart <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Messages about comp.protocols.iso.migration
Am I the only one who's getting annoyed about these long, ISO/egocentric
messages that I tend to get in multiple copies?  Are they going to stop soon?

I like to see discussions of semirelevant topics for a while, and have been
accused of being impressed with myself, but enough is enough.

This opinion is my own, end-of-a-long-day, not well considered, and real. :-|

	Bob

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 13:49:51 GMT
From:      [email protected]  (tom hampton)
To:        [email protected]
Subject:   How long before I can reopen a closed socket?
We have a problem with a socket-based server application which needs to
restart quickly.  What we find instead is that it may take a minute
before the passively binding program can reopen a socket after both
the active and passive binders have terminated.

Is this because

1) We have a bug in ISC 2.2 TCP/IP

2) We are using a "well known address" and these things don't recycle
   instantly after closing (just a wild guess...)

3) We aren't cloising things properly?  We sure think we are, but 
   we notice that the problem gets even worse after an abnormal 
   termination...

-- 
===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
 603 643 1832 
-------------------------------------------------------------------------------
 Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
[email protected]  [email protected]  {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 17:51:34 EDT
From:      Dennis E. Baasch (516) 271-4525 <[email protected]>
To:        [email protected]
Subject:   OSI, X.25 and the INTERNET
	This isn't in response to any particular message, but all of the banter
about OSI and the INTERNET (philosophically speaking) has really been getting
on my nerves. I usually tend to stay out of nonsensical arguments, but in this
case I feed compelled to express my views.

	It seems totally amazing to me that so many very well educated folks
can have such a limited understanding about what's going on in this country
( the United States, that is). Whether its arrogance or ignorance isn't yet
clear, but with all of the propaganda floating around (these lists not
withstanding), I suppose it isn't too surprising. Perhaps the truth isn't as
clear when you don't have many FACTS to work with.

	It seems that anyone with even limited networking experience could
easily come to the conclusion that there is no single solution that will
unite the world. The diversity of applications is much too great, and the
investment in applications much to great to expect any real migration to
any networking concept very much different to what currently exists. The
proponants of OSI are kidding themselves if they think that their concept is
leading them to some sort of utopia; there's a price to pay for generality
and a world screaming for more throughput and functionality is not likely
to sacrifice speed and comfort for 4-wheel drive.

	There's exactly two reasons for the existence (and success) of the 
INTERNET: The AT&T breakup and the fact that it is virtually the only 
supported nationwide network. 

The AT&T breakup: The reasoning behind this may not be obvious to the average
reader, but the AT&T breakup may be the single most significant event in 
modern networking history. In a negative sort of way, that is. In virtually
every modern country in the world all networking is based on a centralize
packet-switching backbone run by the equivalent of what used to be AT&T.
The breakup makes such a network ILLEGAL in the US, at least if implemented
by the phone companies, and has also left the individual phone companies
so talentless that data networking is practically out of their realm of 
understanding. This fact has also left this country so far behind in X.25
technology that few even think about it and almost no-one understands it.
I read a message in which someone referred to X.25 as "ancient technology",
which is quite ironic since in reality it hasn't yet arrived in the US.
This from the people who have proposed PPP, a protocol with half of the
functionality of X.25, none of the networking capabilities and twice the
overhead. The fact is that X.25 is so vastly superior to anything thats 
been proposed in the last 10 years that there's very little reason to 
come up with something else. Its generic transport with a single basic 
concept: logical multiplexing is faster and more efficent than physical
interface management; something that will hold true until busses are
faster than CPUs. The only thing "ancient" about X.25 is the public
switches, most of which are still based on 6809s. But new technology
products with X.25 at T1 speeds are creeping into the marketplace, and 
when they do, the Europeons will be laughing out loud.

While the INTERNET isn't really the only national network, its the only one
thats run for fundamentally unselfish reasons. For E-MAIL and shuffling
around public domain code, its just fine. But if someone came into your board
room and proposed this ratsnest with all of the patchwork protocols,
overburdened routers and (how many hops?) with no link-level error
correction, what would you think?

	I don't have a conclusion to all of this, only a collection of fears.
I'm not sure that I'm even trying to make a point, but if I am, it might be 
something like this: The Europeans may be trying to build a tall building with
short cranes (OSI over X.25), but in the US we're trying to build an equally
ugly edifice on sand (IP over ?). Neither will stand a hurricane, but at least
the Europeans have a basement.


					Dennis
					Emerging Technologies
					[email protected]

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 14:04:16 GMT
From:      [email protected] (Curt Gedak)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: tcp for VMS and tcp over fiber-optics
In article <[email protected]> [email protected] (Mark A Allyn) writes:
>In the future, we may want to install a Sun or other Unix/tcp/nfs type
>goody in the same room as the Macintosh and the printer. What I need help is
>with the following.
>
>The VAX has VMS and DECNET. Because we may have future Unix/tcp type 
>stuff in our environment, we would like to have all communication via TCP.
>I need some suggestions on what software to get for the VAX so that it can 
>run TCP and preferably also NFS. I would also like something that includes
>the necessary libraries and include files so that I can write applications
>using sockets for both stream stuff and datagrams. I have heard of some names
>including Wollengrad (sp?) but don't know anything about them. I need 
>company names and phone numbers.
>
 ... Stuff deleted ....

Process Software Corporation offers a product for the VAX/VMS that supports
FTP, SMTP, TELNET, and NFS.  It can run over the same ethernet that is
concurrently running DECNET.  It is also one of the only products that
states that it supports the DEQNA board (which is not totally IEEE 802.3
compliant).  Their phone number is (508)879-6994.

Note that in no way do I work for Process Software Corporation.  I only
have experience with their products, and have found their technical
support to be very professional.


-- 
Curt Gedak                           uucp: {uunet,alberta}!ncc!isagate!curt
ISA Corporation                       bus: (403) 420-8081
Edmonton, Alberta, Canada.           Home: (403) 992-0591

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 18:16:02 ET
From:      "Rich Woundy" <[email protected]>
To:        [email protected]
Subject:   IP Addresses (Subnets)
 >From: [email protected] (The
 >VolleyDog)
 >Subject: IP Addresses (Subnets)
 >I have a quick question, hopefully you will not flame to loudly with
 >regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 >how to specify a host when using a subnet.  In my particular instance e
 >have a class B network.  I am interested in how one would specify
 >addresses when a subnet of 6 bits is used.
 >
 >Suppose I want the 300th host on the 1 subnet of a class B network wit
 >a netmask of 255.255.252!  Should I specify the IP address as
 >128.38.1.300 or 128.38.253.44
 >
 >I guess my overall question is:  Should I specify the addressing using
 >the 3rd octet field in the dot notation as the subnet or as the 3rd
 >octet of the 32 bit field?
 >
 >Thanks,
 >  Bob Hott
Bob,
   Per RFC 1117, you should specify the addressing using the 3rd octet
of the 32 bit address. The 32 bit address of the 300th host on subnet 1
on network 128.38 should be (by my reading/implementation of RFC 950):

NNNNNNNN NNNNNNNN SSSSSSHH HHHHHHHH N = network,S = subnet,H = host bits
10000000 00100110 00000101 00101100 N = "128.38",S = 1,H = 300
 128    . 38     . 5      . 44      Dotted Decimal Notation

The 6 bit subnet mask you chose allows you to have subnets numbered
1 to 62 (see bottom of page 6 in RFC 950).

As another illustration, note the example (p. 13 bottom, RFC 950)
of the same subnet mask for network 128.99. Address 128.99.4.123
specifies host 123 on subnet 1 on class B network 128.99.0.0.


> From: Frank Kastenholz <kasten%[email protected]>
> From RFC 1117 (Internet Numbers):
> :
>    One commonly used notation for internet host addresses divides the
>    32-bit address into four 8-bit fields and specifies the value of eah
>    field as a decimal number with the fields separated by periods.  Ths
>    is called the "dotted decimal" notation.  For example, the internet
>    address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
>    10.1.0.52.
>
> So, the correct number is 128.38.253.44.
>
> This is not an "official standard" but it is common usage to the degre that
> no one does anything different.
>
> Frank Kastenholz
> Racal Interlan

If this is "common usage", then a router literally following
RFC 950 will handle 128.38.253.44 as net 128.38.0.0, subnet 63 ("252"),
host 300 ("1.44"), assuming the router is privy to the subnet mask.
See RFC 1122 (Requirements for Internet Hosts -- Communication Layers),
pp. 30-31 (condensed here):
  IP addresses are not permitted to have the value 0 or -1 for any of
  the <Host-number>, <Network-number>, or <Subnet-number> fields,
  except in the special cases listed here as either
   <Network-number>,<Host-number>   or
   <Network-number>,<Subnet-number>,<Host_number>
  (a) 0,0   (b) 0,<Host-number>   (c) -1,-1   (d) <Network-number>,-1
  (e) <Network-number>,<Subnet-number>,-1   (f) <Network-number>,-1,-1
  (g) 127,<any>
{See caveats in RFC for cases (a)-(g)}
Note that subnet 63 is equivalent to -1 in the description above.


> From:     Doug Nelson <NELSON%[email protected]>
> The best answer is "none of the above".  If your netmask is 255.255.25.0,
> and you are on the first subnet of network 128.38, then your address rnge
> begins with 128.38.0.0, and ends with 128.38.3.255 (the latter being yur
> subnet broadcast address).  So, if your first host was numbered 128.381.1,
> then your 300th host would be 128.38.2.44.
>
> Doug Nelson
> Network Software Manager
> Michigan State University

Interpreting RFC 950 literally again, 128.38.2.44 specifies host # 556
on subnet 0 on network 128.38.0.0.
The host number space on subnet 1 of network 128.38.0.0 would be
from 128.38.4.1 to 128.38.7.254.

If my answer seems brain-dead, please notify myself and the list.
Otherwise, we're likely to retain three interpretations of the RFCs
to answer a straightforward question. Bob, this was obviously not
a dumb question to ask.

-- Rich
Richard Woundy, IBM Advanced Solutions Development, Milford, CT
Flames to: [email protected]
Disclaimer: IBM nor any other corporation or entity takes responsibility
 for the irresponsible things quoted in this message.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 17:19:04 GMT
From:      usc!zaphod.[email protected]ucsd.edu  (The VolleyDog)
To:        [email protected]
Subject:   Re: IP Addresses (Subnets)
I would like to thank the folks that responded to my request aabout IP
Addresses (Subnetting).  The following is a summary of the responses,
the attachment at the end are the responses I recieved.

  Basically, I asked how to specify the IP address for a class B network
with a 6 bit subnet field and 10 bit host field.  The subnet was # 1, and
the host was # 300.  (I want to thank you for not flaming my mistake for
the octet representation.)  I suggested and octet representation and
a subnet representation.  I suggested an octet representation of
128.38.253.44 (it actually should have been 128.38.5.44) and a subnet
representation of 128.38.1.300.  The responses indicate that the octet 
representation should be used!

  I think it is a shame, since it makes it a little nasty to look
at address 128.38.4.2 and 128.38.5.44 and instantaneously know that they
are actually the same subnet.  I do understand why, and I expected that
this was going to be the case.

  As an aside, the reason I am asking it that I plan to originally
assign the subnet mask as 255 (all 8 bits), but I am afraid that I
may need less subnets, but more host addresses, some I am "planning
ahead".

  Once again, I appreciate your assistance, and your tolerance with
this type of question.

Bob Hott

			Responses Follow
------------------------------------------------------------------------
--------
From: [email protected] (Chuck Kollars - DSGG Technical Marketing - Boston)
Subject: Re: IP Addresses (Subnets)
Organization: Sun Microsystems, Billerica MA

In article <[email protected]> you write:
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.
>
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

Neither.  Host 300 on subnet 1 of net 128.38 with a subnet mask of 
255.25.252.0 should be 128.38.5.44.  

To see why, work it out in binary:

net field mask  11111111.11111111.00000000.00000000 (implied by Class B
address)
net value       10000000.00100110.xxxxxxxx.xxxxxxxx (128.38 w/in its field)

subnet mask     11111111.11111111.11111100.00000000 (255.255.252.0)
subnet field    00000000.00000000.11111100.00000000 (implied, subnet
mask w/o net field)
subnet value    xxxxxxxx.xxxxxxxx.000001xx.xxxxxxxx (1 w/in its field)

host mask       00000000.00000000.00000011.11111111 (implied, inverse of
subnet mask)
host value      xxxxxxxx.xxxxxxxx.xxxxxx01.00101100 (300 w/in its field)

final value     10000000.00100110.00000101.00101100 (128.38.5.44)
 (concatenation of all fields)

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field? 

The octet.octet.octet.octet notation is very old, predating subnets by 
many years.  It happens that if your subnet mask falls on a byte 
boundary (is a multiple of 8 bits long), you can think of one of the 
fields as the "subnet number".  This convenient shortcut doesn't work 
if your subnet mask splits a byte.
--
chuck kollars    <[email protected]>
DSGG Technical Marketing, Sun's Boston Development Center

------------------------------------------------------------------------
--------
From [email protected] Wed Jun 13 14:00:01 1990
Subject: Re: IP Addresses (Subnets)

Hi,

In comp.protocols.tcp-ip you write:
}Suppose I want the 300th host on the 1 subnet of a class B network with
}a netmask of 255.255.252!  Should I specify the IP address as
}128.38.1.300 or 128.38.253.44

The a.b.c.d addressing notation has each portion being one octet.  So,
use 128.38.253.44 for maximum correctness.  But, some versions of some
operating systems may be more permissive: under SunOS 4.0.3, when I
telnet to 128.38.1.300 it responds with: "Trying 128.38.1.44 ...".
Telneting to 10.51 responds with "Trying 10.0.0.51 ...".

-david

------------------------------------------------------------------------
--------
From: [email protected] (Rod King - Sun Consulting Mtn. View)
Subject: Re: IP Addresses (Subnets)
Organization: Sun Microsystems, Mt. View, Ca.

In article <[email protected]> you write:
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.
>
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

This is my vote (and I'm not saying its correct).

The last 2 bytes look like this:
76543210 76543210
subnet|---host--|

host 300 converts to 0x18c in hex.
Filling the bits in the 2 bytes, and using subnet 1, you get
76543210 76543210
00000101 10001100

Converting to IP address notation, you get
5.140 

for an overall IP address of
128.38.5.140.

Life's a lot easier with 8-bit subnets.

Can you also summarize your results?


        Rod King                  email:  [email protected]
        Consultant                office: (415) 336-1897
        Sun Microsystems          FAX:    (415) 968-4356

------------------------------------------------------------------------
--------
From: cpw%[email protected] (C. Philip Wood)
Subject: Re:  IP Addresses (Subnets)

For Class B network:

	128.38.0.0		thats 10000000.00100110.00000000.00000000
				in binary
				
If your subnet is 6 bits then subnet 1 would be:

	128.38.4.0		thats 10000000.00100110.00000100.00000000
	
Host number 300 on subnet 1 would have IP address:

	128.38.5.44		thats 10000000.00100110.00000101.00101100


Did I get that right?

Phil

------------------------------------------------------------------------
--------
From: Frank Kastenholz <kasten%[email protected]>
Subject: Re:  IP Addresses (Subnets)

 > From [email protected] Wed Jun 13 13:08:44 1990
 > From:
[email protected]  (The
VolleyDog)
 > Organization: Naval Surface Warfare Center, Dahlgren VA
 > Subject: IP Addresses (Subnets)
 > Sender: [email protected]
 > To: [email protected]
 > 
 > I have a quick question, hopefully you will not flame to loudly with
 > regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 > how to specify a host when using a subnet.  In my particular instance we
 > have a class B network.  I am interested in how one would specify
 > addresses when a subnet of 6 bits is used.
 > 
 > Suppose I want the 300th host on the 1 subnet of a class B network with
 > a netmask of 255.255.252!  Should I specify the IP address as
 > 128.38.1.300 or 128.38.253.44
 > 
 > I guess my overall question is:  Should I specify the addressing using
 > the 3rd octet field in the dot notation as the subnet or as the 3rd
 > octet of the 32 bit field? 
Bob:

>From RFC 1117 (Internet Numbers):
	
   One commonly used notation for internet host addresses divides the
   32-bit address into four 8-bit fields and specifies the value of each
   field as a decimal number with the fields separated by periods.  This
   is called the "dotted decimal" notation.  For example, the internet
   address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
   10.1.0.52.

So, the correct number is 128.38.253.44.

This is not an "official standard" but it is common usage to the degree that
no one does anything different.

Frank Kastenholz
Racal Interlan

------------------------------------------------------------------------
--------
From: [email protected] (John Romkey)
Subject: IP Addresses (Subnets)

The dotted-decimal notation (128.38.253.44) is just a direct
representation of the 32 bit IP address. It doesn't (necessarily)
break apart neatly into net, subnet and host numbers at dot
boundaries. So the 3rd octet field in the dot notation is equivalent
to the third octet in the 32 bit number.
			- john romkey
USENET/UUCP: [email protected]	Internet: [email protected]
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)

------------------------------------------------------------------------
--------
From: Matt Jonson <[email protected]>
Subject: Re: IP Addresses (Subnets)

Bob Hott <[email protected]> writes:
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field?


The dot decimal notation must break apart into octets, so there is no way
to go over 255 in any given piece.  So, depending on what you mean by
"the 1 subnet", it should look something like this:

     128.38. <6 subnet bits> <2 host bits> . <8 host bits>

host 1,300:            (1)  (256) + (32)+(8)+(4)
     128.38. <0 0 0 0 0 1> <0 1>. <0 0 1 0 1 1 0 0>
			4  +  1       32 + 8+4
  =  128.38.5.44
which is the 300th host on subnet 1, and is on a subnet whose first host is
128.38.4.1, and whose last host (the 1022nd) is 128.38.7.254.  You must
bear in mind that all ones and all zeros in the host portion is reserved.
I think your first subnet would actually be subnet 0, extending from
128.38.0.1 to 128.38.3.254.

Note your netMASK is still 128.38.252.0.  The netmask is only used for
the purpose of masking off the net portion of an ip address, because a logical
AND is performed on the netmask and any given host address (so the zeros knock
off the host number, and the ones pass just the net number) when you're
trying to determine a route for a particular packet. It looks like you got a
little confused on how your netmask relates to your address.

Hope I've been helpful,
MWJ
-------

------------------------------------------------------------------------
--------
From: [email protected] (Michael E. Pare)
Subject: Re:  IP Addresses (Subnets)
Organization: The Internet

>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.

>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field? 

>Thanks,
>  Bob Hott

The first subnet using 6 bits will be 4.  Decimal 300 in binary is
100101100. The rightmost 8 bits belongs to the first field and is 44.
The leftmost 1 is part of the next field.  The resulting binary format
for the first two fields will be :

			00000101 00101100
			------
			subnet|---------|
				host
The resulting decimal values are 5 and 44 respectively.  Thus the IP address
will be 128.38.5.44 for the 300th host of the first subnet.

------------------------------------------------------------------------
--------

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

Fullname:         Robert W. (Bob) Hott
Mailing Address:  Naval Surface Warfare Center
                  Networks Branch (Code E41)
                  Dahlgren, Virginia  22448
DDN Mail:         [email protected]
DDN Mail:         [email protected]
Telephone:        (703) 663 - 7745

"If man were not meant to play volleyball, why are there so many beaches?"
	 - Bob Hott -
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 18:32:41 GMT
From:      [email protected]  (Kent England)
To:        [email protected]
Subject:   Re: Multi-homed hosts and parallel networks
In article <[email protected]>, [email protected] (Steve Jay) writes:
>... Have there been any
> discussions on how IP can cope with multi-homed hosts and (semi-)parallel
> networks, such that traffic automatically takes the "best" path between
> hosts?
> ...
> I put "best" in quotes for a reason.  It may be considered better to have
> some traffic between B & C go over the ethernet rather than the faster
> network.  You may not want to clog up the fast network with the tiny
> packets generated by rlogin, but ftp data connections should be on the
> fast network.
> ...
> The issue is not how to route an IP packet once an IP addresse has been
> selected.  The issue is, how to decide what interface (and which network)
> to use when there is more than one choice...
>
> I'm not looking for "clever" ways to assign names to IP addresses.  I'm
> looking for ideas which might challenge some of the basic IP concepts,
> like names being associated with interfaces instead of hosts, and routing
> decisions based on a name specified by the user/application.  Have these
> issues already been discussed anywhere?  A quick look at the RFC index
> didn't help me.
>
> I'm looking forward to benefiting from the accumulated wisdom on the net.
>

        You might want to consider use of the Type of Service bits
in IP.  We are at the point where we will soon have some new routing
protocols deployed in the Internet which can support TOS routing.

        I noticed TOS coming up a lot at the Pittsburgh IETF meeting
and I did not get the feeling that very many people agreed on what
TOS meant.  Perhaps our wisdom accumulates more like dustballs than
pearls.  Now, if
you can figure out what TOS means according to the "accumulated wisdom"
of the IETF, you might be able to modify your applications to use TOS
with, for example, OSPF routing.  If you don't want to be compliant with
our accumulated wisdom, you might be able to use TOS as you please to
define parameters such as latency, packet size, or even dollar cost.

        You might also have a look at the Open Routing work.  Policy
based routing has a slightly different point of view, but it might
be able to subsume your concerns, on a longer timeframe than TOS routing.
Start with Dave Clark's RFC 1102 and Debra Estrin's RFC 1125.

        Kent England, Boston University
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 18:52:04 GMT
From:      [email protected]  (Mark Roddy)
To:        [email protected]
Subject:   Re: How long before I can reopen a closed socket?
In <[email protected]> [email protected] (tom hampton) writes:

[How Long Must I Wait?]

>We have a problem with a socket-based server application which needs to
>restart quickly.  What we find instead is that it may take a minute
>before the passively binding program can reopen a socket after both
>the active and passive binders have terminated.

>2) We are using a "well known address" and these things don't recycle
>   instantly after closing (just a wild guess...)

In fact you must wait:

	CHORUS: Two Times the Maximum Segment Lifetime!

Which is the minute or two you describe.

The solution is to not use the well known address for the connection -
TCP allows you to accept a connection on a different port address than
the destination address in the connection request.

This is the mechanism used by most *nix TCP/IP services. 

The well-known address is always available to service the 
next incoming connection request.
-- 
-Mark Roddy
Sequoia Systems, Inc.          (508) 480-0800 x1284
[email protected]               m2c!seqp4!markr
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 19:03:51 GMT
From:      [email protected]  (Michael Crawford)
To:        [email protected]
Subject:   Re: Vote for/against "comp.protocols.iso.migration"
In article <[email protected]> [email protected] (Kwang Sung) writes:
>
>	Now I would like to finalize my proposal on creation of a new
>newsgroup "comp.protocols.iso.migration".
>

It is not clear to me that the proper procedure for proposing a new
group, allowing a month or so for discussion, then a month or so for
voting, has been followed.

Please review the policies on this in the groups "news.groups" and
"news.announce.newusers".

It sure seems to me that it is not the proper thing to do to up and
announce a new group for what might more properly be a thread
of discussion in an existing group.

Personally, I would vote against this group until the traffic in the
existing groups on the thread has become enough that it is obnoxious
to filter out by those who are not interested in it.  Also, I would
like to see the discussion exist long enough to be sure it will not
die out after a few weeks.

Please don't be offended, but there has been quite a rash of new groups
lately, like psu.passwd.ne.security.  I would like to see this reigned
in a little.

>	So, could you create a new newsgroup "comp.protocols.iso.migration"
>as soon as possible so that we can discuss seriously and aggressively,
>and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
>any more ??

You do this yourself by asking the news administrator at your site to
issue a "newgroup" command.

-- 
Michael D. Crawford
Oddball Enterprises		Consulting for Apple Computer Inc.
606 Modesto Avenue		[email protected]
Santa Cruz, CA 95060		Applelink: [email protected]@INTERNET#
[email protected]	The opinions expressed here are solely my own.

		alias make '/bin/make & rn'
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 21:07:00 GMT
From:      [email protected] ("Dan Kellen")
To:        comp.protocols.tcp-ip
Subject:   Thanks: I need help with subnetting

   Thanks to all the people that sent help or solutions to my problem.
   I was trying to set up the first subnet on a class B network, without 
   converting the whole network.  We have been assigning addresses as if 
   we were subnetted; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   Here's the solution I implemented.  

   I have configured both interfaces on the subnet gateway and all subnet
   machines on the subnet with class C netmask's and broadcast addresses.
   Meanwhile all other hosts on the network still have their class B netmask.
   I consider this a temporary configuration.

   Getting routing to work was my biggest problem.  Here's what I've done.

   On the subnet machines, I added a default route pointing to the 
   subnet gateway. 
       route add default 129.61.9.2 1

   On the subnet gateway, I added a default route pointing to the main 
   network with a metric of zero. 
       route add default 129.61.2.40 0

   On main network machines that want to talk to the subnet machines I have 
   had to add host routes.  I could not get dynamic routing to do this.
       route add 129.61.9.4 129.61.2.40 1

   Since that time, I have changed my main network gateways to announce a 
   default route via RIP.  I probably should have done this sooner, but we 
   are still moving from static routes to RIP.  I won't have to add the 
   default routes on the next subnet.
   
   I have been watching for broadcast storms, and have seen none.  But, when 
   the subnet gateway RIP's to the subnet 2 broadcast, other RIPers send it 
   a redirect.

   Here's how it looks.

  network: 129.61.0.0       network: 129.61.2.0         network: 129.61.9.0
  netmask: 255.255.0.0      netmask: 255.255.255.0      netmask: 255.255.255.0

                            this int. only             +-----+
                                |                      |     |
                    /\          \/               +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Dan
   ------------------------------------------------------------------
   Digital Equipment Corp.    Internet:  [email protected]
                              EASYnet:   ODIXIE::KELLEN
   System/Network Manager     Internet:  [email protected]
   Eglin AFB, Florida         PHONEnet:  (904)882-5498

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 21:26:30 GMT
From:      [email protected]  (Kraig Meyer)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]> [email protected] (Bill Wisner) writes:
||Oh, come now. Nobody's big enough to need a class A network. Entities
||that have class A networks now didn't get them because they've got big
||networks; they got them for political reasons. MIT and Stanford were
||big with DARPA. MERIT runs NSFNET.

For the record, Merit had its class A net number long before it had
even considered running NSFnet.  The network number Merit got for NSFnet 
was a class B net number.

*****************************************************************************
Kraig Meyer                                                [email protected]
On parole from the University of Southern California.     All views expressed
are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 22:59:53 GMT
From:      swrinde!zaph[email protected]ucsd.edu  (Edward Vielmetti)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]> [email protected] (Kraig Meyer) writes:

   For the record, Merit had its class A net number long before it had
   even considered running NSFnet.  The network number Merit got for NSFnet 
   was a class B net number.

it's also a bit ironic that Merit schools are going to get off of the
class A net number and onto their own class B net(s), at least for
the parts of Merit which will no longer be behind the PDP-11 based
backbone structure (the design which required the class A net in
the first place).   such a shame, I just printed up my Network 35
ID card....

--Ed

Edward Vielmetti, U of Michigan math dept <[email protected]>
"i hear pdp-11's make good flowerpots"
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 23:46:00 GMT
From:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   UDP socket broadcast problem

        I tried to broadcast using UDP socket in Sun OS 4.0.3, sendto() failed
giving error 51 -> Network is Unreachable, is there anything wrong in the
following code segment:

        on = 1;
        if (setsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, sizeof(on))
            < 0)
           syserr("bs_broadcast: setsockopt")

        if (getsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, &onlen) <0)
           syserr("bs_broadcast: getsockopt")
        printf("on=%d, onlen=%d\n", on, onlen);

        /*
         * broadcast address
         */
        remote_sock.sin_addr.s_addr = INADDR_BROADCAST; ------> ???
        remote_sock.sin_family = AF_INET;
        remote_sock.sin_port = htons(remote_port);

        size = sendto(id, buf, buflen, 0, (struct sockaddr *)&remote_sock,
                      sizeof(remote_sock));

        --------------------------------------------------------------------

        I suspect it is something to do with the INADDR_BROADCAST, can anybody
please tell me how broadcast UDP properly? Please reply to me directly.
        Thanks.

- Beng Hang Tay (email: [email protected])

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 01:45:56 GMT
From:      [email protected]du  (Peter da Silva)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
Just for interest sake... would someone on the Internet like to post a list of
the other class A networks. Before any more of them disappear.

I realise it's not likely to be useful to us folks in our little TCP-IP
islands, but what the hell...
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.
<[email protected]>
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 13:30:38 -0700
From:      [email protected] (Merton Campbell Crockett)
To:        [email protected], [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
With all of the ill-maintained systems in this world, would you want a net 10
number for your system?  Let it rest in peace until all other Class A numbers
have been assigned.

As for carving the net 10 address space into additional Class B and Class C
networks, what are the values of the high-order bits of net 10?  As an exer-
cise, explain how you would accomplish this task.  Give examples, if neces-
sary, of what changes you would propose.  If there are any cost impacts, please
identify those costs and provide a plan for recovery of those costs.

You have 2 hours to complete this examination.  Good luck!

Merton
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 01:51:00 GMT
From:      [email protected] (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]>, [email protected] (Frank Kastenholz) writes:
> How about officially assigning NET 10 to Interop - then it could be brought out
> of retirement each year for all of the newcomers to look at - sort of like
> the IMP last year.

Great idea, but make it operational.  After all, the conference net
needs a number; call it net 10, and all the private nets can be subnets
of it.

		--Steve Bellovin

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 09:00:08 PDT
From:      [email protected]
To:        [email protected]du
Cc:        [email protected]
Subject:   Class A Networks (was Mourning of the passing of the ARPANET)
Peter da Silva:

See RFC-1117 "Internet Numbers".

--jon.

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 02:26:02 GMT
From:      [email protected]  (Keith Brown)
To:        [email protected]
Subject:   Re: Vote for/against "comp.protocols.iso.migration"
|TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
|in Korea either.  The big reason here is that the PTTs that implement and
|use the networks in Europe are connection oriented.  They wand Virtual
|Circuits.  TCP/IP is a datagram network and is not acceptable.

***Rubbish!***

This is a subject I feel qualified to talk about. I'm English and spent the
last 5 years working for Excelan (the bulk of who's revenue was derived from the
sale of TCP products) providing support and consulting to our customers
all over Europe. If TCP wasn't popular then somebody was playing a very
cruel trick on me giving me so much work to do every day!

Yes the majority of European WAN's are X.25. That's the service that most of
the PTT's offer to their customers. However, you don't have to be
Gypsy Rose Lee to see that numerous commercial and university sites
are using the X.25 service to carry IP packets between remote locations.
In fact, IP routers that operate across X.25 were becoming very popular
when I left.

The work on ISO is a noble effort. However, speaking as network user
who can today, from the single screen and keyboard on my desk, log in to
all the systems that I need to, get transparent access to the same set
of files from almost all of them, non-transparent access from those
that I can't, shunt files from coast to coast at perfectly acceptable
transfer rates *and* send mail to all my colleagues and friends (even
the ones in the UK), I'm left scratching my head as to what powerful new
goodies the ISO folks are going to bestow upon me. Anybody know?

I'll consider migrating/transitioning/whatever my desktop machine the day
I look over someones shoulder and see him/her doing something useful with
ISO protocols that I can't...

Anyway, this will probably be my last posting on the subject as there
are a few engineers not a million miles from where I'm sitting who'll
probably read this and lynch me in the car park....

These are my humble opinions, not Novell's.
----------------------------------------------------------------------------
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
San Jose, California 95131                       Net:   [email protected]
----------------------------------------------------------------------------
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 03:34:15 GMT
From:      [email protected]  (Brian Kantor)
To:        [email protected]
Subject:   Re:  Mourning of the passing of the ARPANET
We held the wake for net 10 at the Usenix conference, and toasted
it well.  We got well toasted ourselves.  A good time was had by all
reminiscing about all the old good times, fun, and hacks that were
inspired by the grandaddy network of them all.

Bye-bye Arpanet - it was swell!

	- Brian
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 04:45:21 GMT
From:      [email protected]  (Kwang Sung)
To:        [email protected]
Subject:   CALL FOR DISCUSSION: comp.protocols.iso.migration
Hi...

	I would like to apologize for my previous incorrect procedures
to create a new newsgroup. I didn't know how to do it. Please discuss at
"news.groups".

	I would like to propose sincerely to create a new newsgroup 
"comp.protocols.iso.migration".  Here is the purpose on creation:

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection currently, I proposed 
such a newsgroup on USENET. I hope we also can have close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI, etc.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world. For example, we might be able to
discuss many deficiencies on our U.S. GOSIP.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you discuss more about a new newsgroup "comp.protocols
.iso.migration" so that we can create it in the near future ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 15:46 H
From:      <TAYBENGH%[email protected]>
To:        [email protected]
Subject:   UDP socket broadcast problem
        I tried to broadcast using UDP socket in Sun OS 4.0.3, sendto() failed
giving error 51 -> Network is Unreachable, is there anything wrong in the
following code segment:

        on = 1;
        if (setsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, sizeof(on))
            < 0)
           syserr("bs_broadcast: setsockopt")

        if (getsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, &onlen) <0)
           syserr("bs_broadcast: getsockopt")
        printf("on=%d, onlen=%d\n", on, onlen);

        /*
         * broadcast address
         */
        remote_sock.sin_addr.s_addr = INADDR_BROADCAST; ------> ???
        remote_sock.sin_family = AF_INET;
        remote_sock.sin_port = htons(remote_port);

        size = sendto(id, buf, buflen, 0, (struct sockaddr *)&remote_sock,
                      sizeof(remote_sock));

        --------------------------------------------------------------------

        I suspect it is something to do with the INADDR_BROADCAST, can anybody
please tell me how broadcast UDP properly? Please reply to me directly.
        Thanks.

- Beng Hang Tay (email: [email protected])
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 11:52:36 EDT
From:      [email protected]om  (James B. Van Bokkelen)
To:        Frank Kastenholz <kasten%[email protected]>
Cc:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
	How about officially assigning NET 10 to Interop - then it
	could be brought out of retirement each year for all of the newcomers
	to look at - sort of like the IMP last year.....

	Frank Kastenholz

This is an excellent hack!  I'll second it...

jbvb


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 16:21:10 PDT
From:      [email protected]
To:        [email protected]
Subject:   Network Numbers (was Mourning of the passing of the ARPANET)
Hey!

We've got more important problems to solve than to hack the address space.

There are about 16,000 class B address of which we've assigned about
2,500, and only 1,600 active nets of all classes in the interconnected
Internet.

--jon.
 
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 10:44:26 GMT
From:      [email protected].mit.edu  (Peter Mutsaers/100000)
To:        [email protected]
Subject:   broadcast-like kind of stream socket needed
We want to use broadcasts to transmit a lot of data to many computers
at the same time. I wrote a reliable broadcast routine, using (reliable)
stream sockets for a protocol to ensure delivery of arbitrarely large
blocks of data to all receivers. But alas, sending 100k to one host
in this way was about 8 times slower as with stream sockets, so it would
only be useful with 8 or more receivers. I think it must be possible to
do it much better.
I would like to have a new socket type, that has one connection to one
side, and many to the other side, if you know what I mean.
Does anyone know if something like this has ever been written, or
produced on a lower layer, e.g. using raw sockets?
--
Peter Mutsaers                          email:    [email protected]     
Rijksuniversiteit Utrecht                         [email protected]
Princetonplein 5                          tel:    (+31)-(0)30-534504
3584 CG Utrecht, Netherlands                                  
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 16:10:10 EDT
From:      [email protected] (Hal Feinstein)
To:        [email protected], [email protected]
Subject:   Ethernet2 and IEEE 802.3
I've been trying to resolve if 
Ethernet2 can interoperate with
(be on the same cable, talk together) a IEEE 802.3
at the *physical layer*.  I've asked
a number of knowledgeable folk and, while these
discussions were useful, I was left with a range
of answers.  I figure the question 
can't be that hard and someone must have already   
been through this. Roughly, I got these answers:

(1) NO. Both Ethernet2 and IEEE802.3  
can use the same LAN cable system BUT, they cannot
talk (communicate) with each other at the physical layer.

(2) MAYBE. Both (Ethernet2 and IEEE802.3) are very *very*
close (at the physical layer) and maybe functionally 
equivalent.  They SHOULD be above to interoperate and 
coexist on the same cable.

(3) YES. Of course they can. They are a little different
(IEEE802.3 physical layer has a heartbeat and one or two
optional signals) but YES, they can interoperate and 
coexist on the same cable.  

Are any of these the correct answer? SUN seems
to support both physical layers from a single interface. So
I assume that (3) is correct. Am I right?
 
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 12:31:23 GMT
From:      [email protected].mit.edu  (Peter Mutsaers/100000)
To:        [email protected]
Subject:   Why is broadcast so much slower?
When I do a sendmsg() or sendto() on a datagramsocket, the system CPU-time
increases by a factor of ten, on several computers, if I write to a
broadcast address instead of to a single address.
I did ask permission to broadcast on the socket.

Does anyone have an idea why broadcasting is about 10 times as slow,
and maybe know a method to broadcast without so much overhead?
--
Peter Mutsaers                          email:    [email protected]     
Rijksuniversiteit Utrecht                         [email protected]
Princetonplein 5                          tel:    (+31)-(0)30-534504
3584 CG Utrecht, Netherlands                                  
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 14:24:41 GMT
From:      [email protected]  (Joe Ragland)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]>, [email protected]
(Frank Kastenholz) writes:
|> How about officially assigning NET 10 to Interop - then it could be
brought out
|> of retirement each year for all of the newcomers to look at - sort of like
|> the IMP last year. 

Yea, maybe in good ham radio DXpedition style,  Dan Lynch could issue a
certificate for exchanging mail with a net 10 host at Interop?
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 14:38:50 GMT
From:      [email protected]  (John Antypas)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]> [email protected] (Frank Kastenholz) writes:
>
>How about officially assigning NET 10 to Interop - then it could be brought out
>of retirement each year for all of the newcomers to look at - sort of like
>the IMP last year. Maybe during the "off season" Interop could keep 2 PC's
>running in a backroom on some Ethernet, pinging each other - on NET 10.
>
A nice idea, but with all of the talk about address spacing becoming
hard to find, the idea of re-using 10 as a Class A, or splitting it into
256 class B's needs to be considered.  That's a lot of new customers
for Internet.  Consider that net is over 65535 class C spaces!  Do we
want to give Interop 16x10^6 addresses!

John Antypas / Interactive Systems Corp.
uucp: ...!uunet!ism.isc.com!johnan    Internet: [email protected]
All statements above responsability of the author.
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 20:32:35 EDT
From:      Rob Austein <[email protected]>
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
   Date: 5 Jun 90 19:16:59 GMT
   From: [email protected]

   i know alot of people who have used the ITS systems at MIT. i never recall
   them telling me of problems with people "breaking in" and damaging
   something. what security ITS had was based on obsurity. i would like to hear
   from some of the ITS wizards about how security-through-obscurity wrked for
   them. 

It seems that at one point during his romp, Cliff Stoll's "Hanover
Hacker" made his way onto MX.LCS.MIT.EDU (Cliff calls it the "MIT MX
Computer").  According to Cliff, the guy spent about two hours poking
around before giving up.  His net accomplishment during that time was
to figure out how to list one of the GUESTn directories.  I don't
think he got as far as listing the contents of files.  The ITS command
processor is a little, er, eccentric.

--Rob Austein
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 17:14:24 GMT
From:      [email protected] (Randal Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]>, [email protected] (John Antypas) writes:
| A nice idea, but with all of the talk about address spacing becoming
| hard to find, the idea of re-using 10 as a Class A, or splitting it into
| 256 class B's needs to be considered.  That's a lot of new customers
| for Internet.  Consider that net is over 65535 class C spaces!  Do we
| want to give Interop 16x10^6 addresses!

Finding 65535 class C-type customers that all wanted to have their
nets adjacent and one naming authority is a bit much.  There isn't any
way in the current software (pardon my ignorance if there is) to have
non-adjacent subnets.  You can only have "route to net 10" not "route
to 10.11.23", unless you happen to have interfaces that are current
net 10 subnets.

Just to throw my vote in the ring, I don't know who Interop is, but if
they had something to do with the early net, let'em have the number.
By the time we need the 126'th class A address, we'll be hurting in
other ways. :-)

Just another net hacker,
-- 
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III      |
| [email protected] ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 17:20:49 GMT
From:      [email protected]  (Michael Meissner)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]> [email protected] (John
Antypas) writes:

| In article <[email protected]> [email protected] (Frank Kastenholz) writes:
| >
| >How about officially assigning NET 10 to Interop - then it could be brought out
| >of retirement each year for all of the newcomers to look at - sort of like
| >the IMP last year. Maybe during the "off season" Interop could keep 2 PC's
| >running in a backroom on some Ethernet, pinging each other - on NET 10.
| >
| A nice idea, but with all of the talk about address spacing becoming
| hard to find, the idea of re-using 10 as a Class A, or splitting it into
| 256 class B's needs to be considered.  That's a lot of new customers
| for Internet.  Consider that net is over 65535 class C spaces!  Do we
| want to give Interop 16x10^6 addresses!

I suspect you will either have a massive flag day or lots of systems
that will refuse to talk to the proposed carved up addresses.  I
thought there were only ~30-40 class A networks, out of ~126 possible
class A network numbers.  I also seem to remember dimly that class E
network numbers which are not used, were mentioned as means of adding
massive new network numbers.
--
Michael Meissner	email: [email protected]		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 17:25:59 GMT
From:      [email protected]csd.edu  (Mark Towfigh)
To:        [email protected]
Subject:   Re: Vote for/against "comp.protocols.iso.migration"
In article <[email protected]> [email protected] (Kwang Sung) writes:

	   Now I would like to finalize my proposal on creation of a new
   newsgroup "comp.protocols.iso.migration".

Gaah!

	   Here is a list of all persons who have responded to my postings 
   [.....]
	   Obviously, majority wanted to create such a newsgroup on USENET.
   Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

I think this may have been proper procedure in 1982.

   [.....]
	   So, could you create a new newsgroup "comp.protocols.iso.migration"
   as soon as possible so that we can discuss seriously and aggressively,
   and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
   any more ??

Bother the people directly involved in this issue?

   Persons who have responded to my proposal so far:
   [list deleted]

This is ridiculous.  Comp.protocols.iso *maybe* had about two articles
a day in it before this "proposal" came up, and it jumped to a
whopping five after that.  I see *no reason* for the creation of a new
newsgroup, especially since the normal procedures for group creation
have been disregarded, or garbled at best.

Kwang: read news.announce.newusers.  I think you would probably
realize from there that there is *no need* for an ISO migration group;
relevant articles can just be crossposted to
comp.protocols.{iso,tcp-ip}.

Mark
--
Mark Towfigh, Racal InterLan, Inc.                 [email protected]
W: (508) 263-9929 H: (617) 488-2818                       uunet!interlan!towfiq

  "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 19:27:50 GMT
From:      [email protected]  (Joshua L Mindel)
To:        [email protected]
Subject:   UUCP (AT&T BNU) over STREAMS-based TCP/IP/(Ethernet,X.25)
Initial part of question:
-------------------------
Does anyone have experience with setting up uucp (AT&T BNU) files on 
AT&T 3B2s for a STREAMS-based network?  In particular, for AT&T Enhanced 
TCP/IP WIN/3B Release 3.0 over Ethernet and X.25.

Background:
-----------
I'd like to configure BNU files (on AT&T 3B2s with UNIX System V Release 3.2.2)
so that uucp and cu requests both go through login to connect over an Ethernet
and X.25 network.

Section 9.6 of the AT&T 3B2 Computer UNIX System V Release 3 Sys Admin guide 
provides guidelines for setting up uucp on a STREAMS-based network.  An example
procedure is included for uucp on the AT&T STARLAN network, with the qualifier 
that a similar procedure could be applied for setting up uucp to run on a 
transport provider that is compatible with the AT&T Transport Interface (TLI).

The WIN/3B TCP/IP Release 3.0 product is a transport provider compatible with 
TLI.

After scouring the AT&T Sys Admin guide, WIN/3B docs, and talking with 
Wollongong, I came to realize that there is one critical piece missing from
this picture; the STREAMS module(s) providing the interface between the TTY 
server and TCP.  Using AT&T's terminology for describing the software 
components of a uucp-over-STARLAN configuration, these STREAMS modules are
called Remote Login Modules.  For uucp over STARLAN, these STREAMS modules are 
called LDO and NTTY.

Final part of question:
-----------------------
Do these remote login modules exist for TCP/IP?  If yes, how and where can
I obtain them?

Further clarification of question:
----------------------------------
Leaning heavily on the definition used within the STARLAN environment, I presume
the precise function of these missing modules can be stated as follows:

The remote login modules are the software modules that act as an interface
between the TCP modules and the remote login services provided by the TTY
server.  These modules provide the UNIX character processing and read/write
interface of the standard TTY driver.  This allows existing UNIX TTY
services ("sh", "cu", etc.) to operate over the TCP/IP network.

Paper references for this note:
-------------------------------
 WIN/3B TCP/IP Install/Admin Guide : pages 1-20 to 1-23
 AT&T STARLAN User's Guide	   : pages 4-3 to 4-4

------------------------------
Thanks in advance.

-- 
-------------------------------------------------------------------------------
Joshua L Mindel, Senior Analyst		Internet:  mindel%[email protected]
NetWorks One				Usenet:	   uunet!netwrx1!mindel
Vienna, VA				Phone:     (703) 827-7767
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 20:25:06 GMT
From:      [email protected]  (Amanda Walker)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
In article <[email protected]>, [email protected] (Joe Ragland) writes:
> Yea, maybe in good ham radio DXpedition style,  Dan Lynch could issue a
> certificate for exchanging mail with a net 10 host at Interop?

I'm beginning to like this idea more and more...

It could also be fun to give the show backbone routers "historically
significant" IMP names, so that you could do traceroutes and so on...

--
Amanda Walker, InterCon Systems Corporation
--
"Y'know, you can't have, like, a light, without a dark to stick it in...
 You know what I'm sayin'?"     --Arlo Guthrie
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 20:41:14 GMT
From:      [email protected] (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: How long before I can reopen a closed socket?
In article <[email protected]>, [email protected] (Mark Roddy) writes:
> The solution is to not use the well known address for the connection -
> TCP allows you to accept a connection on a different port address than
> the destination address in the connection request.
> 
> This is the mechanism used by most *nix TCP/IP services. 
> 
> The well-known address is always available to service the 
> next incoming connection request.

No, that's not quite correct.  A TCP connection is defined by the
4-tuple <localhost,localport,remotehost,remoteport>.  Servers define
the first two parts -- on Berkeley-derived systems, via the bind() call.
When a client connects, a connection is instantiated with a fixed
pair of values for <remotehost,remoteport>.  The server's partial
connection -- or rather, the under-specified TCB for its passive
open -- can still exist; that's an implementation issue.

What happens on Berkeley-derived systems is that you get a new file
descriptor in the server for each connection; the port numbers
don't change.  However, the kernel will not let you bind even a
server port if any TCBs exist with the same <localhost,localport>
portion, even if all of the others have <remotehost,remoteport>
filled in.  You can override this via setsockopt() with the
SO_REUSEADDR option.  Inetd does exactly that.

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 22:21:21 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.e[email protected]ucsd.edu  (Lars Henrik Mathiesen)
To:        [email protected]
Subject:   Re: How long before I can reopen a closed socket?
[email protected] (Mark Roddy) writes:

>In <[email protected]> [email protected] (tom hampton) writes:
>>2) We are using a "well known address" and these things don't recycle
>>   instantly after closing (just a wild guess...)

>In fact you must wait:

>	CHORUS: Two Times the Maximum Segment Lifetime!

>Which is the minute or two you describe.

>The solution is to not use the well known address for the connection -
>TCP allows you to accept a connection on a different port address than
>the destination address in the connection request.

>This is the mechanism used by most *nix TCP/IP services. 

This turns out not to be the case, at least in the Berkeley
implementation of TCP/IP (also known as Berkeley sockets). This is
what happens: The server process creates a socket and uses bind(2) to
associate it with the well known port number for its service. However,
a socket has two address/port pairs, one local and one foreign.
Bind(2) only sets the local part, so that the socket will accept
connections from any client. (Each client uses connect(2) to set the
foreign part on its socket and make a connection).

When a connection is established, a new socket is created and passed
to the server process (returned from accept(2)). This new socket has
its foreign address part set to the client's.

When a TCP connection ends, the party which sends the last packet in
the protocol (the FIN ACK) has to wait a short time after that to see
if it was lost (if so, the other party resends its last packet, the
first sends FIN ACK and waits again). That's your minute. Note that
its the party that closes first that gets to wait.

When you try to start a new server, it has to bind(2) the same
address. The system will not allow that if there an existing protocol
control block conflicts with the address. In 4.3-tahoe, conflict is
defined as follows:
	A) The address pairs are the same. In UNIX, this may happen if
some server subprocesses haven't closed the original socket descriptor
(Berkeley rlogind, e.g.).
	B) The new address pair would match some packets which
``belong'' to an existing control block. In 4.3-tahoe, this test is
not performed if either
		1) SO_REUSEADDR has been set with setsockopt(2) or
		2) listen(2) has been called on the socket and the
protocol is connection-oriented (as TCP is). If the test is done,
server-client connections in the wait state will block the bind(2),
even though the file descriptor has been closed.

So: Check if all child processes of the server have gone away; if not,
take care that they close the original socket before they start
processing. Also, call listen(2) before bind(2) if your implementation
allows it, otherwise set SO_REUSEADDR (ditto), otherwise complain to
your vendor.

It is strange that the 4.3 IPC tutorials all show the use of bind(2)
before listen(2), when the kernel works ``better'' with the opposite
order.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      [email protected]
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 02:24:01 GMT
From:      [email protected]
To:        [email protected]
Subject:   Re: Ethernet2 and IEEE 802.3
In article <[email protected]>, [email protected] (Hal Feinstein) writes:
> 
> I've been trying to resolve if 
> Ethernet2 can interoperate with
> (be on the same cable, talk together) a IEEE 802.3
> at the *physical layer*.  I've asked
> [Text deleted]

3 is correct. There is a difference between SQE and heartbeat, but those are
really specific to transceivers, not the media. In any case, they certainly do
operate on the same cable.

I understand that interoperation on a common physical layer was a requirement
for the 802 committee.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: [email protected]
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 02:28:54 GMT
From:      [email protected]  (Lance C Norskog)
To:        [email protected]
Subject:   Re: SLIP reliability
[email protected] says:

> In my personal experience (which includes supporting a lot of TCP/IP
> nodes), I have only had one report of undetected data corruption in
> TCP (a transposition caused by a device driver bug while transferring
> a very repetitive raster file).  The combination of TCP and IP on
> SLIP seems fairly robust in practice: For two years our Internet link
> was leased-line SLIP, and I am using dial-up SLIP to send this, and
> I've never seen an error that got past the checksum.  This may be
> because there is a good match between the errors asynch lines tend to
> generate and those the checksum is likely to detect.

2 points: 
	1) If your NFS uses WD cards or any other card based on the National
chip set and does not use UDP checksums, you will get file data corruption
big-time.  The National 8390 Ethernet chip likes to randomly add and drop
bytes when copying twixt RAM and Ethernet; this is, of course, outside the 
enforcement range of the Ethernet checksum.

	2) If your SL/IP tosses packets when the hardware gives framing
or lost-byte errors, SL/IP should be very reliable.  If you run SL/IP over
modems, be sure to use MNP or some other error-corrected protocol.  These 
modems are so cheap that it's pointless running on a raw one.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Jun 90 09:18:55 EDT
From:      Hans-Werner Braun <[email protected]>
To:        [email protected]
Subject:   NSFNET Expansion and T3 upgrades.
Subject: NSFNET Expansion
Date: Wed, 13 Jun 90 16:52:04 EDT
From: Douglas Gale <[email protected]>

NSF creates worlds fastest openly available network for 
research and education.

The National Science Foundation (NSF) has announced a $7.9 
million expansion of its nationwide computer network,  the 
NSFNET.  In addition to adding three new nodes or connections 
to the backbone of the NSFNET, data transmission speed on 
several key links of the existing network will be increased to 
45 million bits of information per second to create the world's 
fastest openly available network for research and education.

The sites that will be linked by the higher speed connections are 
Cambridge, Massachusetts, Ithaca, New York, Pittsburgh, 
Pennsylvania, Ann Arbor, Michigan, Urbana-Champaign, Illinois, 
Argonne, Illinois, San Diego, California, and Palo Alto, California.  
The technology used to support the higher transmission speeds will 
support the development of the proposed very high speed National 
Research and Education Network (NREN).

The new nodes on the NSFNET backbone network will be located 
at the Massachusetts Institute of Technology in Cambridge, 
Massachusetts, Argonne National Laboratory in Argonne, 
Illinois, and Georgia Institute of Technology in Atlanta, 
Georgia.  The Cambridge node will connect the New England 
Academic and Research Network, NEARnet, to the NSFNET.  In 
addition to providing connections to Argonne National 
Laboratory, the Argonne node will provide additional 
connections to CICnet which serves institutions in the upper 
Midwest.  The Atlanta node will provide additional connections 
to the Southeastern University Research Association Network, 
SURAnet.

The new sites will augment the existing 13 nodes which 
connect mid-level networks to the network backbone.  The 
mid-level networks in turn link computers in more than 1,000 
university, government and industrial research institutions 
throughout the world.

"The network is used to access resources such as 
supercomputers, libraries, and satellite data, as well as to 
link geographically dispersed researchers, educators, and 
scholars," according to Dr.Stephen Wolff, Director of the 
Division of Networking and Communications Research and 
Infrastructure at the National Science Foundation.

The NSFNET backbone network is managed and operated by the 
Merit Computer Network from its state-of-the-art network 
operations center on the campus of the University of Michigan 
in Ann Arbor, Michigan, as part of a cooperative agreement 
with NSF. Merit's partners in the project include IBM 
Corporation, MCI Communications Corporation, and the State of 
Michigan through its Strategic Fund.  MCI Communications 
Corporation will provide advanced circuit switching 
technology for the expansion capable of a twenty-eight fold 
increase in current backbone transmission speed.  IBM 
Corporation will deploy a new generation of technology to take 
advantage of the increased capacity of the expanded network.


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 07:46:07 GMT
From:      [email protected]  (Sue Miller)
To:        [email protected]
Subject:   RCP sources/info wanted
Hi, I'm looking for publicly available source for a RCP (remote copy program)
to transfer files from a UNIX host under TCP/IP protocols.  Either a socket or
other implementation would be useful.  I'm trying to put a copy function within
the body of another program.

Any communication on this subject would be welcome - my uucp address
is  ...!sun!hoptoad!wet!sue.  Thanks!

Seth Olitzky
Louth Systems
(415) 329-9498
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 00:08:02 PDT
From:      [email protected] (Hilarie K. Orman)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
Networks whose response was lame,
And the packets dropped, before the name.

Do not ask for whose net the ^G tolls ...


  Hilarie Orman ([email protected])
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 06:59:04 -0700
From:      [email protected] (Merton Campbell Crockett)
To:        [email protected], [email protected], [email protected]
Subject:   My Cup Overfloweth
What's with this:

        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        ...

I'm beginning to prefer the discussion on our collective short-sightedness
for not having ten blind men define the Internet protocol suite for DARPA
and being so destitute that we can't afford to follow the one, true Faith.

If there are any PAC*BELL readers of this group, a slip down the racks and
a sudden, unscheduled service outage would not go unappreciated.

Merton

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 19:24:33 GMT
From:      [email protected]  (Stuart Lynne)
To:        [email protected]
Subject:   Re: SLIP reliability
In article <[email protected]> [email protected] (Lance C Norskog) writes:
>	2) If your SL/IP tosses packets when the hardware gives framing
>or lost-byte errors, SL/IP should be very reliable.  If you run SL/IP over
>modems, be sure to use MNP or some other error-corrected protocol.  These 
>modems are so cheap that it's pointless running on a raw one.

There are other issues. When you turn MNP on you increase (the already bad)
latency of packets traversing the link.

We run SLIP over a V.32 modem (T2500). We could turn on the reliable mode,
but find we get better performance if we don't. 

-- 
[email protected] ubc-cs!van-bc!sl 604-937-7532(voice) 
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 21:07:18 GMT
From:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   Re: Motrning of the parsinf of the [email protected]
In article <[email protected]>, [email protected] (Joe Ragland( writes:
> Yea, maybe in good h`m radio DXpedithnn rtyle,  Dan Lynch could hssud a
> certifhcatd for exbhanfing mail with a net 10 host at Interop?

I'm befinnhng to like this ide` more and more...

It could also be fun to five the shov backbond routers "historically
significant" IMP nales, so that you could do tracernutes and so on...

--
Amanda Walker, InterCnn Systems Corporatinn
--
"Y'knov, you can't have, lhke, a light, without a dark to stick it in...
 Ynu know what I'm sayin'>"     -,@rln Guthrid

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 12:28:48 -0700
From:      Marshall Rose <[email protected]>
To:        [email protected]
Subject:   Computer Project Would Speed Data
Computer Project Would Speed Data 


NY Times, Friday, June 8, 1990

Businesses, Schools and U.S. Agencies to Join in Effort

By JOHN MARKOFF

The National Science Foundation plans to announce today that a large  
group of the nation's leading communications  and computer companies  
universities  and research laboratories and several Government agencies  
will begin development of a high-speed network that will allow computer  
data to be transmitted at speeds almost 700 times faster than possible  
over existing networks. It would be the first comprehensive attempt in  
the United States to advance the critical technological area of computer  
networks and is being called an important model for cooperation between  
business and government.

The widespread support for the computer network project stands in sharp  
contrast to the reception received by other recent cooperative projects  
in high technology such as the effort to finance research in high- 
definition television and the joint venture known as U.S. Memories, that  
was intended to strengthen the United States in the semiconductor  
business. Those projects have foundered for lack of money or enthusiasm  
among Government and business. In Japan, the government and large  
corporations have already begun work on high-speed computer networks,  
known as data highways, that enable the transmission of the equivalent  
of about 160 hefty novels every second compared with only about two  
novels every second in even the fastest networks today.

By conveying so much data so quickly, using the same optical-fiber  
cables now used by some long-distance telephone carriers, high-speed  
computer networks hold the promise of many new scientific and commercial  
uses , that could be available by the middle of this decade. These  
include the ability to transmit to and receive data from a hybrid of  
television and computer. The new device would have a picture and sound  
of movie-like quality and the capacity to allow the viewer to manipulate  
the images and data displayed on the screen and instantaneously exchange  
the information with other users.

Other potential uses that could evolve from the new project include  
three-dimensional medical imaging that allows doctors thousands of miles  
apart to analyze lifelike, high- resolution images; far more accurate  
understanding and prediction of weather and climate because of the  
ability to link the power of supercomputers around the country, and  
multimedia teleconferencing that would combine video images and computer  
data, allowing business meetings without the need to travel.

$100 Million From Companies

The data network is being initiated with $15 million from the National  
Science Foundation and from a Pentagon agency that has financed research  
in basic technology. But more than $100 million will come from  
companies. including the International Business Machines Corporation and  
the American Telephone and Telegraph Company, during the three-year  
project, executives at the foundation said.

The venture "marks an important step forward," said Robert B. Reich, a  
Harvard University economist. "There are a host of technological areas  
in which the United States is falling behind to which this model might  
be directly applicable if it means developing skills and insights in new  
technological areas," he said.

The computer-network project will draw together dozens of corporations  
and universities, including I.B.M. AT.&T., the MCI Communications  
Corporation, the regional Bell telecommunications companies and  
universities including the Massachusetts Institute of Technology, the  
University of Pennsylvania, the California Institute of Technology and  
the University of California at Berkeley. Government laboratories  
including those in Los Alamos, N.M., and Livermore, Calif. and the  
nation's five supercomputer centers will also participate.

A Pioneer's Brainchild

The project is the brainchild of Robert E. Kahn, a pioneer of the  
nation's first computer network experiment, called Arpanet, and David J.  
Farber, a computer scientist at the University of Pennsylvania. Mr. Kahn  
is president of the Corporation for National Research Initiatives, a  
computer technology research group in Reston, Va., that will receive the  
Government grant expected to be announced today.

Mr. Kahn was director of computer science research at the Defense  
Advanced Research Projects Agency, the Pentagon agency participating in  
the project. Mr. Kahn said that he would not comment on the project  
until it had been formally announced by the National Science Foundation.

Computer scientists said significant technical challenges remain to  
allow the transmission and reception of computer data at speeds above a  
billion bits per second, a goal of the new network.

Transmitting computer data is clone in a way similar to the way mail has  
traditionally been sorted in post offices, said William A. Wulf, a  
computer scientist at the University of Virginia. Postal employees read  
addresses and place envelopes in particular slots.

Similarly computer networks break data into packets, send them as  
strings of digital signals and then sort them when they arrive at their  
destination. The problem with very high speed networks, said Dr. Wulf,  
is that even the fastest machines that serve as gateways between the  
data highway and the computers they connect are not able to keep up with  
the stream of 1's and 0's possible with new networks. The challenge is  
therefore to develop a new class of ma- chines to serve as gateways.

The development project consists of five experimental networks.

The effort represents the first phase of a multi-year endeavor that  
supporters hope will ultimately create the national data highway.

Project developers said they are still uncertain about the cost of  
deploying a nationwide high-speed network. It is possible, they contend,  
that the rapidly increasing technology of long-distance optical-fiber  
networks may generates a surplus in capacity, permitting low-cost  
delivery of data and digital video services.

Support of Gore

"This represents a great example of how industry and government can work  
together to develop a key technology needed for the effective use of a  
national network of data super- highways soon to put in place," said  
Senator Albert Gore Jr., Democrat of Tennessee. "It's not a huge amount  
of money but if it will provide a great many useful applications for the  
network."


Senator Gore has introduced legislation that would finance the cost o  
developing a high-speed compute network to link the nation's super  
computer centers.

The Bush Administration has said it supports a national high-speed  
computer network but has not committed to backing new financing for the  
project.

One scientific project that will rely on the network will link a radio  
telescope array at the University of California at Berkeley with a Cray  
II supercomputer at the National Center for Supercomputer Applications  
in Champagne-Urbana, ILL., and computer work stations at the University  
of Maryland. Such a network would permit astronomers to use radio  
telescopes interactively in ways never before possible, said Larry  
Smarr, director of the supercomputer center.

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 90 04:17:27 GMT
From:      [email protected]  (Dave Carter)
To:        [email protected]
Subject:   Networking RT11
i have some micro pdp11/23's running rt11 which collect large amounts
of data, which i then transfer to our file server, a microvax II
running ultrix.  this part of our network is running tcp/ip.
currently i am using a pc as the console for the pdp, and i have to
kermit the files from the pdp to a drive on the pc which is actually
on the file server - the pc is running pc/tcp/nfs. (funny how i have
to use an ibm to get two pieces of dec equipment to talk to each 
other :-) kermitting the files is getting tedious, and i would like
to be able to store the files directly on the file server.

i know that rt11 does not support decnet over ethernet, so my question
is this: does anyone have a simple solution with a tcp/ip network?  is
there an nfs-type solution?  (i would like to get rid of rt11, but
that is not a possibility.)

							- dave
[email protected]
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 17:09:22 EDT
From:      [email protected]
To:        [email protected]
Subject:   more to argue about . . . . . .
i mean, hey, life is *too* short, right?


last monday, at the router requirments working group, we discussed subnet
bits. we discussed what we would require a router to support. there is talk
about variable lenght subnet bits. there is talk about someone writing an
RFC on such things. if you are out there, please mail to me. we also talked
about non-contigious subnet bits. we were not sure that anyone was using
non-contigious subnet bits. there does seem to be strong interest in
variable lenght subnet masks, though.


so, where is the arguement, you ask? i mean, you *know* i am getting there,
right? 

router requirments is thinking of requiring support for variable lenght
subnet bits, but explicitly saying that a router does not have to implement
non-contigious subnet bits (MAY in host requirments parlance).


he ya go, campers. anyone wish to rise up and define a good reason to keep
non-contigious subnet bits, assuming we require the ability to have more
than one address on an interface . . . . . .

your input on this matter is most appreciated.

stev knowles
[email protected]
617-246-0900

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 23:55:01 MDT
From:      cpw%[email protected] (C. Philip Wood)
To:        [email protected]
Subject:   The Portal System (TM)
I'm tired of it.

Phil Wood
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 00:24:50 MDT
From:      cpw%[email protected] (C. Philip Wood)
To:        [email protected]
Subject:   Who would mourn the passing of the Portal System (TM)?
Not me.

Phil
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 09:49:07 -0700
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   Re: router requirements (was: more to argue about)
Steve Knowles suggests that variable length subnet masks should be a
requirement while non-contigious subnet bits should become a MAY in the new
router requirements.  This may not be an issue that needs to be addressed on
the general TCP-IP list; however, since it has been raised:

I believe such a change in policy is premature.  In general, I believe that
changes in basic Internet requirements should be made with caution, since each
change has major significance for all the vendors who try to track the IP
suite, and each change decreases our credibility as a stable networking
platform.  Of course, we have to make necessary changes...

I don't see much wrong with dropping the requirement for support of
non-contiguous masks.  Granted, this feature has been enshrined in code and
standards for years, but few sites actually use it, and some existing IP
protocols (notably the new DNS network number stuff and OSPF) break it.  I'm
all for simplicity.

However, the other proposed change is one whose time has not yet come.  No
standard reachability protocol currently supports variable length subnets, and
only one of the competing routing protocols does so (if and when OSPF becomes
a required standard, that will change things!  Does the router requirements
working group propose to require OSPF also?).  Realistically, it will be a
long time before most vendors of products that do routing are ready to support
OSPF (concrete and important example: Shiva FastPath); a warning that this is
the intended direction of the Internet is appropriate now, but a requirement
is not.

Conclusion:  make variable masks a SHOULD, not a MUST.  Make OSPF a SHOULD
too.
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 12:01 -0700
From:      <[email protected]>
To:        morrison%thucydides.cs.uiuc.edu%ux1.cso.uiuc.edu%uwm.edu%zaphod.mps.ohio-state.edu%[email protected], [email protected]
Subject:   Re:  PCroute 2.1 release out
I got 'permission denied' when I was trying ftp for PCroute2.1.

[email protected]
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 06:11 EST
From:      VGCHAC <[email protected]>
To:        TCP-IP Interest Group <[email protected]>
Cc:        "Prof. Frank Vanacek" <802-485-2580%[email protected]>
Subject:   
Subject: Voice Recognition Conference


In the absence of knowledge of other distribution lists
more appropriate, I am taking the liberty of posting this
conference notice on TCP-IP at the request of the conference
organizers.

Vint Cerf

-------

        VOICE RECOGNITION CONFERENCE

August 22-24, 1990
Stowe Flake Inn
800-782-9009
Stowe, VT 05672


The conference is sponsored by the Weschester County Chapter
of the ACM and organized by:

   Prof. Frank Vanacek         Prof. Walter Kosinsky
   Norwich University          Cybertree, Inc.
   Northfield, VT 05663        RFD #1
   FAX: 802-485-2580           Wolcott, VT 05680
   TEL: 802-485-2205

Topics:

  Recognition algorithms
    speech units, language model, spoken language understanding

  Applications

  Feature Extraction (e.g. metrics)

  Recognition database (creation, maintenance, search)

  Speaker training/adaptation

  Unique hardware devices


Conference registration fees:

  $65 for non-ACM members
  $55 for ACM members (note your member number)
  $45 for students

All fees due and payable in US currency before conference
and are non-refundable

Provisions for demonstration equipment at Stoweflake Inn
can be provided - must arrange with Prof. Kosinsky or
Prof. Vanacek in advance.

A 1 page abstract should be mailed or faxed to Prof. Vanacek.
Papers should be limited to 10-20 pages total.


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 08:40:10 MST
From:      [email protected] (Kanchei Loa)
To:        [email protected]
Subject:   add to mailing list
  Please add me to the tcp/ip mailing list.

Thanks


Kanchei Loa
Email: loa%[email protected]
Phone# 602-8975122
Software Engineer/Networking
Network Design & Development
Semiconductor Products Sector
Motorola Inc.
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 08:41:43 PDT
From:      <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   more important things to do (was Network Numbers (was Mourning of the passing of the ARPANET))
   From: hamachi!Sun.COM!portal!cup.portal.com!sun!portal!cup.portal.com!sun!venera.isi.edu!portal!
   Lines: 11
   Date: Sat, 16-Jun-90 23:07:41 PDT
   X-Origin: The Portal System (TM)
   X-Possible-Reply-Path: sun!portal!cup.portal.com!sun!venera.isi.edu!portal!
    [email protected]
   X-Possible-Reply-Path: sun!portal!cup.portal.com!sun!portal!cup.portal.com!
    sun!venera.isi.edu!portal!cup.portal.com!postel

Could you *PLEASE* DO SOMETHING ABOUT THIS!!!!!!!!!!!!

Sorry to yell, but its been going on for a while.

I had 20+ copies of each and every tcp-ip message for the last several
days. Its not nice to put over 300 messages into people's mailboxes.

note to tcp-ip'ers: can I claim a record for most-abused (most
overstuffed) mailbox ?? :-(

How about a new RFC: "A Protocol For the Remote Disabling of
Mis-configured Mailing List Exploders and Aliases By Hardware
Detonation".

Nuke 'em 'til they glow, shoot 'em in the dark.

Tom Perrine (tep)                       |Internet: [email protected]
Logicon                                 |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division  |-or-  sun!suntan!tots!tep
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 02:08:25 GMT
From:      [email protected] ("Rich_Woundy"[email protected]@[email protected]@[email protected], al.com)
To:        comp.protocols.tcp-ip
Subject:   IP Addresses (Subnets)

 >Frol: [email protected] (The
 >VolleyDog)
 >Subject: IP Addresses (Subnets)
 >I have a quick question, hopefully you will not flame to loudly with
 >regard to  viewhng RFCs.  I looked through RFC 850 to try tn determine
 >how to specify a host when using a subnet.  In my particular instance e
 >have a class B network.  I al interested in how nne vould specify
 >addresses when a subnet nf 6 bits is used.
 >
 >Ruppose H want the 300th host on the 1 subnet of a class B network wit
 >a netmask of 255.255.252!  Should I specify the IP address as
 >128.38.1.300 or 128.38.253.44
 >
 >I guess my overall question hs:  Should I specify the addresring using
 >the 3rd octet field in the dot notation as the subndt or as the 3rd
 >octet of the 22 bit field>
 >
 >Thanks,
 >  Bnb Hott
Bob,
   Per RFC 1117, you should specify the addressing using the 3rd octet
of the 32 bit address. The 32 bit addresr of the 300th hnst on stbnet 1
on ndtwork 128.38 should be (by ly rdading/implementation of RFC 950):

NNNNNNNN NNNNNNNN SSSSSSHH HHHHHHHH N = netwnrk,S = subnet,H = host bits
10000000 00100110 00000101 00101100 N = "128.38",S = 1,H = 300
 128    . 38     . 5      . 44      Dottdd Decimal Notation

The 6 bit subnet mask you chose allows you to have subndts numbered
1 tn 62 (see bottom of page 6 in RFC 950).

As another illustration, note the example (p. 12 bottom, RFC 950)
of the same subnet mask for network 128.99. Address 128.99.4.123
specifies host 123 on subnet 1 on class B network 128.99.0.0.


> Frnm: Franj Kastenholz <kasten%[email protected]>
> From RFC 1117 (Internet Numbers):
> :
>    One commnnly used notation for internet host addresses divides the
>    32-bit address into four 8-bit fields and specifies the value of eah
>    field as a decimal number with the fields separated by periods.  Ths
>    is called the "dotted decimal" notation.  For example, the internet
>    address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
>    10.1.0.52.
>
> So, the correct number is 128.38.253.44.
>
> This is not an "official standard" but it ir common usage to the degre that
> no one does anything different.
>
> Frank Kastenholz
> Racal Interlan

If this is "common usage", then a router literally following
RFC 940 will handle 128.38.253.44 as net 128.38.0.0, subnet 63 ("252"),
hnst 200 ("1.44"), assuming the rnuter is privy to the subnet masj.
See RFC 1122 (Requirements for Internet Hosts -- Commtnication Layers),
pp. 30-31 (condensed here):
  IP addrdsses are not permitted to have the value 0 or -1 for any of
  the <Host-number>, <Network-number>, or <Subnet-number> fields,
  except in the special cases listed here as either
   <Network-number>,<Host-number>   or
   <Network-nulber>,<Subnet-number>,<Hnst_number>
  (a) 0,0   (b) 0,<Hnst-number>   (c) -1,-1   (d( <Network-number>,-1
  (e) <Netvork,number>,<Subnet-number>,-1   (f( <Network-number>,-1,-1
  (g) 127,<any>
{See caveats in RFC for cases (a)-(f)}
Note that subnet 63 is equivalent to -1 in the description above.


> From:     Dnug Nelson <NELSON%[email protected]>
> The best answer is "none of the abovd".  If your netlask is 255.255.25.0,
> and you are nn the first subnet of ndtwork 128.38, then your address rnge
> begins with 128.28.0.0, and ends with 128.38.3.255 (the lattdr being yur
> subnet broadcast address).  So, if your first host was numbered 128.381.1,
> then your 300th host would be 128.38.2.44.
>
> Doug Nelsnn
> Netwnrk Software Manager
> Michigan State University

Interpreting RFC 850 literally again, 128.38.2.44 specifies host # 556
on subnet 0 on netwnrk 128.38.0.0.
The host number space on subnet 1 of network 128.38.0.0 would be
frnm 128.38.4.1 to 128.38.6.254.

If my answer seels brain,dead, pleasd notify myself and the list.
Otherwise, we're likely to retain thred interpretations of the RFCs
to answer a straightforward question. Bob, this was obviously not
a dulb question to ask.

-- Rich
Richard Woundy, IBM Advanced Solutions Development, Milford, CT
Flames to: [email protected]
Disclaimer: IBM nor any other corporation or entity takes responsibility
 for the irresponsible thinfs quoted in this message.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 8:57:14 CDT
From:      Evan Wetstone <[email protected]>
To:        [email protected]
Subject:   Enough Already!!!!
How about sending an ICMP (Internet Control Mailing-list Protocol)
source quench to portal.com?

-- 
Evan Wetstone
Network & Systems Support
Rice University, Houston TX
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 09:13:43 EDT
From:      Bill Streilein <[email protected]>
To:        [email protected]
Subject:   multiple subnets, single interface
In article <[email protected]>,
[email protected] writes:
> ... I would like to know if any of
> the commercially-available TCP/IP packages have the capability of either:
> 
>      1)  sending and receiving IP packets for more than one subnetwork
>          over the same Ethernet interface.
> 
>  or: 2)  routing packets between two or more subnetworks over the
>          same Ethernet interface.
> 
> We have several spare Ethernet bridges but only one router - a Cisco.

Wellfleet Communications offers this capability in version 5.30 of it's
software.   However it is not limited only to multiple subnets -- multiple 
non-subnetted interfaces are possible as well.
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 09:16:37 EDT
From:      [email protected] (Hal Feinstein)
To:        [email protected]
Subject:   The Portal System (TM)
I now count 12 copies of two messages to me on Ethernet2 vs IEEE802.3.
These are being sent to me under various origins But each has
Portal headings. Shut it off!!!!
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 10:24:09 EDT
From:      SSJACK%[email protected]
To:        TCP-IP LIST <[email protected]>
Subject:   Netmasks
Which RFC(s) explains the interpretation and usage of netmasks?

========================================================================
Jack E. McCoy                                     [email protected]
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 10:27:33 EDT
From:      SSJACK%[email protected]
To:        TCP-IP LIST <[email protected]>
Subject:   Domain name server setup
I've acquired an unsupported DNS program for which there is NO documentation.
By sifting through the RFC on DNS, I've managed to bring the server up. It
appears to be working correctly.

However, one of the configuration files contains an entry for 'localhost'
along with an address of 127.0.0.1. What is the purpose of this?

========================================================================
Jack E. McCoy                                     [email protected]
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 06:36:05 GMT
From:      [email protected]  (Kraig Meyer)
To:        [email protected]nic.ddn.mil
Subject:   comp.protocols.iso.migration and tcp/ip in korea
With the latest flurry of arguments about how much tcp/ip is or isn't
used in Europe/Asia/etc., I thought people might be interested in 
reading  "National network takes shape in Korea," which is in the most
recent issue of the CERFnet news.

It outlines the expansion of "the nation's backbone network," and mentions
"The primary network protocol used by KREOnet is TCP/IP with some SLIP."
*****************************************************************************
Kraig Meyer                                                [email protected]
On parole from the University of Southern California.     All views expressed
are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 10:36:49 EDT
From:      [email protected] (Dennis Perry)
To:        portal!cup.portal.com!sun!portal!cup.port[email protected]sun.com, [email protected]
Cc:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
I am not certain why DARPA does not just keep net 10 as their network
number for their internal network, afterall, it would then remain usable
by those who started it all anyway.  They could also use it for their
experimental network, which is what the arpanet was when it started.

dennis
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 08:19:46 GMT
From:      [email protected]  (Matthew Lewis)
To:        [email protected]
Subject:   NEEDED: SLIP for Sun OS 4.0.3, A/UX 1.x
As the subject says... The Sun OS 4.0.x changes didn't build under 4.1,
and I just started looking for the A/UX version.

Thanks in advance,

Matthew Lewis
Sys Admin, CICT
Univ. of Amsterdam

-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: [email protected]			The Netherlands
UUCP:	  uunet!mcsun!hp4nl!uvabick!matthew
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 12:57:43 edt
From:      [email protected] (Paul Tsuchiya)
To:        cup.portal.com!sun!p[email protected]portal, [email protected]
Subject:   Re:  more to argue about . . . . . .
I have been working out a scheme for general yet efficient addressing
ABOVE the network level.  (In IP, this would obviously mean changing
the class A/B/C style of addressing, so maybe its impossible.  For CLNP,
the issue of address definition is still open).  Anyway, the only
way to do it such that 1) addresses are used efficiently, like %50
utilization, 2) any number of hierarchy levels can be encoded (limited
of course by the number of bits in the address), and 3) expansion can
occur at any level without invalidating existing assignments, is to
allow for non-contiguous masks.

Now, again this is for above the network level, not below it, so I
don't know that this is really important at the subnet level.  It
depends on how much hierarchy exists within a network, and how much
the hierarchy changes.  My personal opinion is that the generality
is nice, and it doesn't necessarily slow down implementations (for
instance, patricia and of course cacheing still work).  However,
probably most folks don't want to deal with non-contiguous masking.

If anyone is interested, I will be presenting my ideas at the UBC
IETF, and have a draft paper.  Mail me a request if you want a
copy.

PT

_________________________________________________________________
Paul F. Tsuchiya		Bellcore
[email protected]	435 South St.
201-829-4484			MRE 2L-281
201-267-9298 (FAX)		Morristown, NJ 07960
_________________________________________________________________ 
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 10:08:28 GMT
From:      [email protected]  (Guus van der Wal)
To:        [email protected]
Subject:   KA9Q ( NOS ) question
Hi netland,
I recently downloaded the new KA9Q ( NOS ) version.
It came with no documentation, just the binary.
As I am a NET user already, and have read through the
documentation (890421.1 revision) I didn't consider it
as a too serious problem.
ONLY, NOS works, but is not able to resolve hostnames
from HOSTS.NET (like the previous version) or doesn't
use HOSTS.NET at all.
Is this a change in this version or is NOS lacking this
facility completely.
May this is described in a piece of docs that I don't (yet)
have.
Who can help ??
                  Guus

-- 
Guus van der Wal
Computing Centre Delft University of Technology, The Netherlands
USEnet: [email protected]
BITnet: [email protected]
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 22:41:47 -0700
From:      [email protected] (JQ Johnson)
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re: router requirements (was: more to argue about)
I'm at home, so I don't have my OSPF RFC handy.  I thought when Moy
gave in to non-contiguous subnet bits in OSPF he held out for
hierarchical, i.e.  did not allow general non-contiguous subnets.  For
example he would not be able to compute the most specific match given:

	     subnet	  mask
subnet A:  128.223.2.0 255.255.3.0
subnet B:  128.223.1.0 255.255.5.0
subnet C:  128.223.4.0 255.255.6.0

At the time, I suggested some mechanisms for resolving the dillema,
which I could probably recover from old mail.  But I thought they
hadn't been adopted.

Is my recollection of the RFC faulty?
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 11:11:00 GMT
From:      [email protected] (VGCHAC)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Voice Recognition Conference


In the absence of knowledge of other distribution lists
more appropriate, I am taking the liberty of posting this
conference notice on TCP-IP at the request of the conference
organizers.

Vint Cerf

-------

        VOICE RECOGNITION CONFERENCE

August 22-24, 1990
Stowe Flake Inn
800-782-9009
Stowe, VT 05672


The conference is sponsored by the Weschester County Chapter
of the ACM and organized by:

   Prof. Frank Vanacek         Prof. Walter Kosinsky
   Norwich University          Cybertree, Inc.
   Northfield, VT 05663        RFD #1
   FAX: 802-485-2580           Wolcott, VT 05680
   TEL: 802-485-2205

Topics:

  Recognition algorithms
    speech units, language model, spoken language understanding

  Applications

  Feature Extraction (e.g. metrics)

  Recognition database (creation, maintenance, search)

  Speaker training/adaptation

  Unique hardware devices


Conference registration fees:

  $65 for non-ACM members
  $55 for ACM members (note your member number)
  $45 for students

All fees due and payable in US currency before conference
and are non-refundable

Provisions for demonstration equipment at Stoweflake Inn
can be provided - must arrange with Prof. Kosinsky or
Prof. Vanacek in advance.

A 1 page abstract should be mailed or faxed to Prof. Vanacek.
Papers should be limited to 10-20 pages total.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Mon 18 Jun 90 16:30:48-CDT
From:      Matt Jonson <[email protected]>
To:        [email protected]
Subject:   Re: My Cup Overfloweth
I must say that one wild mail relay sure makes all the previous reasons 
that people used to moan about wasted bandwidth seem pretty insignificant.

I suppose the C0WABUNGA D00DS posting caused the cup to crack...
or maybe it's just a symptom of migration.to.iso...

Matt
-------
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 12:54:02 GMT
From:      PIRARD%[email protected] (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   IP-routers vs SNA-bridges

     Our University is interconnecting LANs where TCP/IP is growing,
but where IBM SNA and, to a lesser extent, DECnet are also used [1].
The problem is how to partition our network physically and subnet my
class B address. Should I recommend our management to:

1) use bridges (they pass SNA), ignore recommendations against a
single large IP network and not subnet our address [2]. An IBM
argument is the speed of bridges (of course). I am told they (the
bridges:-) are less expensive, but is it a good deal?

2) use "recommended subnetting" with b-routers. I am told they are
*very* expensive, if ever to be found.

3) try very hard to transport SNA, DECnet and maybe Novell over IP and
use plain routers (more expensive than bridges [3]), arguing
that migration to ISO [4] will be easy. Do any product do that transport,
preferably with promised/expected migration?

4) use a large bridged core for SNA+IP with routers to IP-only
networks [5]. How feasible are different address masks, will I need
another network address?

5) any other solution but dropping SNA?

     Many thanks for reports of experience, advices, pointers to
products or even a plain "x is it". Please cc: me in an answer to the list.

[1] Unhappily, TCP/IP needs quite a lot of hacking to provide
international characters support while IBM has that ready made.
[2] They say some do (including Microsoft), how real are the dangers?
[3] But I have tested to the exact contrary the excellent software
PCROUTE. I feel it can be a real money saver in many situations.
[4] or OSI, depending on mood *and* language :-)
[5] Unhappily, all networks with PCs will probably want SNA
capability.

Andr'e PIRARD
SEGI Univ. de Li`ege
B26 - Sart Tilman
B-4000 Li`ege 1 (Belgium)
[email protected] on EARN alias BITNET
[email protected] from Internet

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:24:09 GMT
From:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   Netmasks
Which RFC(s) explains the interpretation and usage of netmasks?

========================================================================
Jack E. McCoy                                     [email protected]
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:27:33 GMT
From:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   Domain name server setup
I've acquired an unsupported DNS program for which there is NO documentation.
By sifting through the RFC on DNS, I've managed to bring the server up. It
appears to be working correctly.

However, one of the configuration files contains an entry for 'localhost'
along with an address of 127.0.0.1. What is the purpose of this?

========================================================================
Jack E. McCoy                                     [email protected]
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:39:13 GMT
From:      [email protected]  (stanley.b.king)
To:        [email protected]
Subject:   Re: Mourning of the passing of the ARPANET
I, for one, mourn the passing of all these duplicate articles
through my news server.

Stan King, [email protected]
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:50:08 GMT
From:      bacchus.pa.dec.com!shlump.[email protected]decwrl.dec.com  (Esa Laitinen)
To:        [email protected]
Subject:   Re: Printing from a PC to a DECserver printer
PCSA would be fine in there, and would offer even more than only the printing.

Esa Laitinen, whose opinions might not be even his, save his employers
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:58:29 GMT
From:      [email protected]  (Nick McKeown)
To:        [email protected]
Subject:   Re: SLIP reliability
Fred Goldstein writes:

> Frog two 16-bit words and you've got an undetected error.

Not sure what "frog" means, but re-assure me that if you
were to swap any two 16-bit words round (on a 16-bit boundary)
then the error would go undetected...

Nick McKeown
HP-Labs
Bristol, UK
[email protected] 
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 16:29:08 GMT
From:      [email protected]  (Rick Jones)
To:        [email protected]
Subject:   Re: Why is broadcast so much slower?
When you say that the cpu load increases on several computers, do you
mean that several computers on the same network at the same time, or
are you just refering to the cpu usage to send the broadcast packet?
The difference is important, I'll assume the former case...

One possible reason that the broadcasting is so slow is that the
broadcast packet you are sending is generating a 'broadcast storm' on
your wire. If you are sending an apropriately nasty packet, and there
are systems who have not learned that 'thou shalt not ICMP a broadcast
packet,' you can get a nice little storm.  I am familiar with some
systems that will try to ARP or otherwise address resolve subnet
broadcasted IP addresses and ignore the broadcast nature of the packet
(breaking the 'thou shalt not' rule). If you send an ICMP Echo request
to a broadcast address, similiar results may occur.  

You probably want to trace your wire to see exactly what is going on,
however, because without any 'real' data, this is all just speculation...

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | Yes, MPE Speaks TCP/IP...
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 01:05:28 PDT
From:      [email protected] (Hilarie K. Orman)
To:        [email protected]
Subject:   Knowledge-is-Power Department
My sense of frustration at the portal fiasco was alleviated this
evening when I glanced at a recently obtained copy of "!%@:: A
Directory of Electronic Mail Addressing and Networks", by Donnalyn
Frey and Rick Adams, and learned that Portal is a General Subscription
Service based in Cupertino, offering UUCP and USENET feeds.  Its voice
number is 408-973-9111, and it takes email at [email protected]  This
sort of information suggests more constructive activities to take
against email blizzards than sending mail into the fray and becoming
part of the problem.  Like this note.  I hope no one has to see it
more than once.

  Hilarie Orman
  [email protected]
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 14:54:02 +0200
From:      Andr'e PIRARD <PIRARD%[email protected]>
To:        [email protected]
Subject:   IP-routers vs SNA-bridges
     Our University is interconnecting LANs where TCP/IP is growing,
but where IBM SNA and, to a lesser extent, DECnet are also used [1].
The problem is how to partition our network physically and subnet my
class B address. Should I recommend our management to:

1) use bridges (they pass SNA), ignore recommendations against a
single large IP network and not subnet our address [2]. An IBM
argument is the speed of bridges (of course). I am told they (the
bridges:-) are less expensive, but is it a good deal?

2) use "recommended subnetting" with b-routers. I am told they are
*very* expensive, if ever to be found.

3) try very hard to transport SNA, DECnet and maybe Novell over IP and
use plain routers (more expensive than bridges [3]), arguing
that migration to ISO [4] will be easy. Do any product do that transport,
preferably with promised/expected migration?

4) use a large bridged core for SNA+IP with routers to IP-only
networks [5]. How feasible are different address masks, will I need
another network address?

5) any other solution but dropping SNA?

     Many thanks for reports of experience, advices, pointers to
products or even a plain "x is it". Please cc: me in an answer to the list.

[1] Unhappily, TCP/IP needs quite a lot of hacking to provide
international characters support while IBM has that ready made.
[2] They say some do (including Microsoft), how real are the dangers?
[3] But I have tested to the exact contrary the excellent software
PCROUTE. I feel it can be a real money saver in many situations.
[4] or OSI, depending on mood *and* language :-)
[5] Unhappily, all networks with PCs will probably want SNA
capability.

Andr'e PIRARD
SEGI Univ. de Li`ege
B26 - Sart Tilman
B-4000 Li`ege 1 (Belgium)
[email protected] on EARN alias BITNET
[email protected] from Internet
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 19:19:35 GMT
From:      u[email protected]ucsd.edu  (Johnny zweig)
To:        [email protected]
Subject:   Re^2: IP Addresses (Subnets)
[email protected] (The VolleyDog) writes:
>
>  Basically, I asked how to specify the IP address for a class B network
>with a 6 bit subnet field and 10 bit host field....
>The responses indicate that the octet representation should be used!
>
>  I think it is a shame, since it makes it a little nasty to look
>at address 128.38.4.2 and 128.38.5.44 and instantaneously know that they
>are actually the same subnet.

The dotted-decimal notation isn't really designed to make things easier to
think about (I maintain that 6 bit fields inside octet-delineated
representations are intrinsically difficult to deal with), just easier to
talk about with people who don't know hexarithmetic as well as they know
decimal arithmetic. I would have a hard time converting 128.38.1.300 into
binary without having already been told that the fourth number represents
the last 10 (as opposed to 8) bits; but if you have to tell somebody the
subnet mask anyway, then it's in fact harder to convert 128.38.1.300 into
binary than 128.28.4.2.  While I acknowledge that it's hard to figure out
that 128.38.4.xx and 128.38.7.yy are on the same subnet off the top of your
head, I think being faced with numbers like 128.38.1.6 that I can't turn
into binary (how many bits for the last ".6"?) is almost as barfy.

In short: Networking is complicated(*).

-Johnny Subnet

(*) If nobody else has yet claimed ownership of this three word phrase, I
think it should be called Zweig's Axiom. If it has, what is it's Official
(tm) name?
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 23:22:50 EDT
From:      [email protected] (Rob Coltun)
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re: router requirements (was: more to argue about)
I'm all for dropping the requirement for support non-contiguous
subnet bits.

>... and some existing IP
>protocols (notably the new DNS network number stuff and OSPF) break it.
I don't understand. OSPF will support non-contiguous subnet bits.

> Realistically, it will be a
> long time before most vendors of products that do routing are ready to support
> OSPF
Just around the corner...

---rob
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 20:02:00 GMT
From:      [email protected]s.ohio-state.edu  (Bob Kalal)
To:        [email protected]
Subject:   Unix Based Mail and Information Server
I apologize for the wide cross-posting, but we need to get
to the broadest cross section of experience.

We have been looking into developing a unix-based solution 
to the problem of replacing an older system at Ohio State. 
The older system is a Dec 20 running TOPS-20 and serves 
as a campus time-sharing information resource (electronic 
mail, bulletin boards, usenet news, etc). It carries about 
a thousand active accounts and has about 450 logins per 
day with a maximum of about 50 at one time. The new 
system would also pick up lighter information service 
loads from a small unix system and another non-unix system.
 
We have gone through an RFI process and identified several
attractive and cost-effective open system technologies.
We are currently looking at clustering two or more 
binary-compatible newer-generation risc-based deskside 
servers with SCSI or IPI disks. The units would have 
a small number of serial ports on a campus port selector 
and ethernet access to the campus TCP/IP network (SONNET) 
or telnet logins. They would share a private ethernet 
for inter-unit traffic from NFS disk mounts, etc. 

Initial user software would include Columbia MM, unix 
mail commands, Usenet news software, and several editors 
including Gnu EMACS, and a third-party EDT. We would plan 
o run the units as one Yellow pages domain and to NFS cross 
mount all but some unit-specific local disk areas on all 
servers.

Our goal would be to have the  user environment appear the
same regardless of the specific unit. We would develop, 
port, or purchase load balancing and distribution software.
We expect the load to grow and would add servers and disk 
as it increases. Newer servers could be tailored for
specific function and location and might not be identical 
to the first units. Large storage servers could be a 
possibility with growth.
 
The vendors and technologies we are looking at include Sun
with the sparc-based Sparcserver 470 (a deskside version 
of the 490) running SunOS; Solbourne with thesparc-based 
601 single-processor server running SunOS; Dec with a 
MIPS-based server running Ultrix 4; and IBM with the 
RS 6000 model 520 running AIX 3.
 
Does anyone have experience with this sort of cluster in a
unix environment? What is your reaction to the approach?
To the hardware and software? How do you feel about the 
various vendors' approaches to memory use and managment,
context switching, and serial or ethernet communications?
 
Thanks in advance for your help and sharing. I'll summarize
responses.
 
Bob Kalal   (614)-292-4843
The Ohio State University
Instruction and Research Computer Center
1971 Neil Avenue
Columbus, Ohio 43210
 
[email protected]
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 20:54:33 GMT
From:      usc!zaph[email protected]ucsd.edu  (Edward Vielmetti)
To:        [email protected]
Subject:   Re: Portal
In article <[email protected]> [email protected] (Havana - Moon) writes:
   You may contact Portal by phone (voice) for the information you desire.
   Call 408/973-9111 (9-5 Pacific time).  

Except the number was busy when I called.

--Ed

Edward Vielmetti, U of Michigan math dept <[email protected]>
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 22:02:39 GMT
From:      zaphod[email protected]tut.cis.ohio-state.edu  (Jim McCrae)
To:        [email protected]
Subject:   Re: Vote against "comp.protocols.iso.migration"
I really have to wonder why this is such a big deal. Leave
the discussion here, so we have something to discuss. If transition
isn't a paramount issue to this newsgroup it should be. Sorry for the
clutter; just amassing mail in opposition to the new group.

		Jim McCrae -> Network Equipment Technologies, RWC CA
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 22:12:40 GMT
From:      [email protected] (Michael O'Brien)
To:        comp.protocols.tcp-ip
Subject:   Re:  Mourning of the passing of the ARPANET

In article <[email protected]>, [email protected] (Brian Kantor) writes:
|> We held the wake for net 10 at the Usenix conference, and toasted
|> it well.  We got well toasted ourselves.  A good time was had by all
|> reminiscing about all the old good times, fun, and hacks that were
|> inspired by the grandaddy network of them all.

I think it's appropriate that the Arpanet wake was partitioned.  There were
two wakes in two different bars simultaneously.
--
Mike O'Brien
[email protected]

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 22:17:09 GMT
From:      usc!zaphod.mps.ohio-state.edu!uaka[email protected]ucsd.edu  (Mark Crispin)
To:        [email protected]
Subject:   Re: anonymous ftp, and the dangers thereof
In article <[email protected]> [email protected] (Rob Austein) writes:
>   Date: 5 Jun 90 19:16:59 GMT
>   From: [email protected]
>
>   i know alot of people who have used the ITS systems at MIT. i never recall
>   them telling me of problems with people "breaking in" and damaging
>   something. what security ITS had was based on obsurity. i would like to hear
>   from some of the ITS wizards about how security-through-obscurity wrked for
>   them. 
>
>It seems that at one point during his romp, Cliff Stoll's "Hanover
>Hacker" made his way onto MX.LCS.MIT.EDU (Cliff calls it the "MIT MX
>Computer").  According to Cliff, the guy spent about two hours poking
>around before giving up.  His net accomplishment during that time was
>to figure out how to list one of the GUESTn directories.  I don't
>think he got as far as listing the contents of files.  The ITS command
>processor is a little, er, eccentric.

I don't see why people thing ITS's command parser is particularly
eccentric (^x means CTRL/x, $ means ESC):

ITS			bsd UNIX		TOPS-20

^R foo			cat foo	{or} more foo	TYPE foo
^R foo;..NEW. (UDIR)	mkdir foo		BUILD <foo>
$R foo,bar		cp foo bar		COPY foo bar
SYS^K $$^R		adb -wk /dev/kmem	^EQUIT {then} /
^F			ls			DIRECTORY
0^F			cd ~;ls			CONNECT {then} DIRECTORY
foo^F			ls ~foo			DIRECTORY <foo>
^O foo			rm foo			DELETE foo
$^O foo,bar		mv foo bar		RENAME foo bar
$$^O foo,bar		ln bar foo		{none}
foo^K			foo			foo {or} RUN foo
^Z			^Z			^C
$P			fg			CONTINUE
^P			bg			CONTINUE STAY
{none}			^C			{none}
$^X.			kill n			RESET
$$U			^D {or} logout		LOGOUT
{normal state}		gdb foo			DDT

Obviously, of the three ITS was the most intuitive.

 _____   | ____ ___|___   /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105
 _|_|_  -|- ||   __|__   /  / 6158 Lariat Loop NE   "Gaijin! Gaijin!"
|_|_|_|  |\-++-  |===|  /  /  Bainbridge Island, WA "Gaijin ha doko ka?"
 --|--  /| ||||  |___|    /\  USA 98110-2098        "Niichan ha gaijin."
  /|\    | |/\| _______  /  \ "Chigau. Gaijin ja nai. Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 09:17:46 EDT
From:      [email protected] (Michael E. Pare)
To:        [email protected]
Cc:        [email protected]
Subject:   Terminal Server Response Time
I am in the process of trying to decide whether to provide a group of VAX
users who are in need of terminal servers with LAT servers or TCP/IP servers.
The later is preferrable because that's what we support here at the Institu-
tion.  No, I'm not looking for servers that provide both.  I have a TCP/IP
server I use now (3COM CS200's which won't be supporting LAT until 1991).

The problem of support lies in the response time of any TCP/IP server to 
various control signals under VMS due to the packet sizing.  Under LAT,
which is specifically designed to work only with LAT hosts on the same
local network, you get immediate response to such control characters as
^C or ^Y, etc.  With TCP/IP, when you issue a ^C or ^Y you must wait
until the packet(s) already sent by the host roll through your screen
before you see the break or interrupt take effect (say for example you
are typing a file to your screen).  I can control the situation with ^C
because I can set it as a break character on the server and the server will
react to it by issuing an inband or out-of-band break and flush the packets.
However, with ^Y, which in this example would stop the output until you
issue a continue command on the host, you must wait for an additional few
screens of output to go by before it stops.  If you set this as the break
character to flush packets, the output will stop immediately but when you
do a continue you will have lost a lot of data.

The hosts in my situation are various DEC machines running under VMS and 
using DEC's UCX TCP/IP software.  DEC has not shown us a way to change the
TCP packet size.  Ideally I think we need to reduce the Telnet packet size
to provide better response time for terminals without affecting the FTP
transfer rate.  I also have this problem on one host running Wollongong
TCP/IP software.

Has anybody out there run across this situation and been able to resolve it?
I even asked 3COM about it since they have VAXes at their site but they
could not provide me with a solution.  I would appreciate any help with this
so I can decide whether to go ahead with installing additional TCP/IP
servers or have to go with LAT servers to provide the proper response time.

Thanks in advance.

--Michael Pare', P.Eng.
  Woods Hole Oceanographic Institution 
  Woods Hole, MA 02543
  (508) 457-2000x2861
  [email protected]
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Tue 19 Jun 90 15:34:40-PDT
From:      William "Chops" Westfield <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: more to argue about . . . . . .
One thing that on-contiguous subnet masks are useful for is converting
a PSN (IMP) based network to more modern technology.  Consider the
MilNet or ARPANet - the IP address of a host is something like:
	10.HOST.0.IMP, or 26.HOST.0.IMP

To map this to a modern network, the "imp" field can be reused as
the subnet, and things work moderately elegantly and nicely.

Bill Westfield
cisco Systems.
-------
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 12:04:14 GMT
From:      [email protected]  (Jon Allen)
To:        [email protected]
Subject:   Re: Ethernet2 and IEEE 802.3
In article <[email protected]> [email protected] writes:
>In article <[email protected]>, [email protected] (Hal Feinstein) writes:
>> 
>> I've been trying to resolve if 
>> Ethernet2 can interoperate with
>> (be on the same cable, talk together) a IEEE 802.3
>> [Text deleted]
>
>3 is correct. There is a difference between SQE and heartbeat, but those are


It is also a good idea to match the transceiver to the interface.  If the 
host interface is 802.3physical, then you should use an 802.3 compliant 
transceiver (and vice versa).  

Using this method I have had no problems mixing Ethernet I, Ethernet II and 
802.3 (physical) devices on the same cable talking to each other.


-Jon
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 13:52:38 GMT
From:      [email protected]  (Peter Zepter A )
To:        [email protected]
Subject:   TCP/IP Gateway for Novell NetWare
We are using Racal InterLan TCP Gateway for Novell NetWare Version 1.4 
and installed it with an original IBM AT03 under Novell NetWare 286 Version
2.12. The Personal Computers using Novell Software are connected via an IBM 
Token Ring Network, the TCP/IP is used via original Ethernet. We are using 
Sun SparcStations under SunOS 4.03 and DEC Vaxstations with VMS.
The quality of the software and its documentation is not very good. Thus we
have some problems with the gateway. Perhaps anyone has solutions to the follwing
questions:
1. rsh
  1.1 The usage of the "-l" option in connection with the ".rhosts" file is not
      correct. The gateway software transfers the name given with the "-l"   
      option to the remote host and not the NetWare loginname as required.
      example: gateway                : doki
	       Novell user name       : ze
	       .rhosts file           : ....
			                doki ze
			                ....
	       remote host            : sun2
               username at remote host: zepter
	       The following command line in DOS by user "ze" does not work:
		 rsh sun2 -l zepter cat ...
      You can only use the command if you change the .rhosts file line from
      "doki ze" to "doki zepter". But in this case any (!!!) user can exe-  
      cute rsh on account "zepter", which is quite dangerous. Is there any
      possibility to use 'rsh' in the usual correct way?
  1.2 rsh does not accept any input from DOS neither by a pipe (|) nor by
      input redirection (<). Any attempt to do this leads to a crash of the
      PC. Are there any possibilities to circumvent this?

2. We are using telnet with German Keyboards attached to the PC. How can we
   obtain characters like brackets ("[", "]"), braces ("{", "}") and vertical
   bar ("|") on these keyboards? Using an "ALT CTRL" combination as usually
   does not lead to any success.

3. How can we use the "printer" service listed in the SERVICES file? We want
   to use a printer connected to the Novell file server via TCP/IP from our 
   UNIX workstations.

4. The route command does not accecpt symbolic names defined in the NETWORKS
   file (error message: bad value). The only way to route to a subnet seems
   to be the use of the explicit destination option "net" in connection with
   the explicit internet address of the subnet. The route show command then
   shows a network address consisting of all zeroes, but the routing seems to
   work. Can this be improved?


We would be very pleased if you could help us with any of these questions.

Peter Zepter ([email protected])
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 12:15:11 +0100
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected]
Subject:   Re: router requirements (was: more to argue about)
JQ, I sent out a message about this to the router requirements list, but
let me follow up briefly here with some major points:

1)	Variable length subnet support has been shipping in at least one
vendor's product for almost a year now I believe.  Van Jacobsen's 4.4
BSD IP forwarding code supports it, and with no performance penalty
over traditional methods.  His patricia tree work has been well
documented and reported on in IETF and in other bodies.  I don't think
this is a radically new concept.

2)	The router requirements document will mandate a number of things that
far fewer people implement today, like the requirement for recognizing
broadcast packets based on the media level destination address (you remember
that a packet came in via a media level broadcast, and don't just use the
destination IP address to determine if it was a media level broadcast).  To
the best of my knowledge, the only IP router code that supports this is 
Phil Karn's KA9Q code, and I think maybe 4.4 now.  This means it's seen 
a lot less experience than variable length subnets.  But, it's "the right
thing" to do.  So it's required.  It's certainly not hard, and certainly
can be done fairly easily.

3)	If we were just waiting for OSI to come and save us, then sure,
we could struggle along with kludges to the problem, and justify it
because we were waiting for OSI to save us.  Well, the IETF took this
approach several years ago.  This approach changed when it was realized
that OSI wasn't just around the corner, and that we had better fix some
things so that we could grow the network to the size we need.  That's
when efforts like SNMP, OSPF, ORWG, and other critical efforts got 
started.  Personally, I feel that we have to add features or we won't
be able to do our jobs.  OSI has it's own set of problems to deal
with, and I think it's going to be a long time before non CS types are
doing real work with it (at least that's my opinion, coming from NASA,
who tends to want to use the network for non-CS types of use).

4)	We have to be able to streamline management and ease of
use of IP networks.  We have been seeing an explosion in th number of
IP nets in use in recent years.  But there is still a lot of kludges and
tricks a manager needs to know to do his job effectively when faced
with certain sets of problems.  Some have said that there are ways
to do what you need to do without explicit variable length mask 
support, but they are not completely effective, and certainly require
a lot more overhead in terms of setup and support that just fixing
the problem.  And if you screw up, you can easily cause a network meltdown.
Now, it's true that the wizards could probably exert enough thrust to
get things to function reasonably well.  But this is not an option 
for most sites, since wizards are very hard to come by!  We MUST make 
IP network management more turn-key.  Standard IGP's, and MIB's, and 
things like variable length mask support make that possible.  It's not
just research network out there.  When things are broken, people can't
get their work done.  

In short, I think you are being overly pessimistic.  I would also point
out that Stanford and Ames both have very capable staffs, and can probably
kludge things so they work.  But look at the bigger picture...  We have a 
responsibility to move forward in this area.  If not us, who?  If not now, 
when?

						Thanks,
						   Milo

PS Usual disclaimers apply...
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 13:56:18 GMT
From:      [email protected]tate.edu  (Jose Angel Vela Avila)
To:        [email protected]
Subject:   Re: KA9Q (NOS) and HOSTS.NET
>>>>> On 19 Jun 90 10:48:13 GMT, [email protected] (Guus van der Wal) said:
> Hi netland,
> I recently downloaded the new KA9Q ( NOS ) version.
> It came with no documentation, just the binary.
> As I am a NET user already, and have read through the
> documentation (890421.1 revision) I didn't consider it
> as a too serious problem.
> ONLY, NOS works, but is not able to resolve hostnames
> from HOSTS.NET (like the previous version) or doesn't
> use HOSTS.NET at all.
> Is this a change in this version or is NOS lacking this
> facility completely.
> May this is described in a piece of docs that I don't (yet)
> have.
> Who can help ??
>                   Guus


  I get it too, and the documentation says that it change to : /domain.txt

   But I have another problem, if I tell to NOS that route all packet to a 
    subnet 131.178.10.x with the following command :
    route add 131.178.10/24  Interface
   It says me : Unknown Host 131.178.10/24    Why ?


  Can anybody help ?

  Thanks


 [email protected]
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 13:58:54 GMT
From:      [email protected]  (Diptish Datta)
To:        [email protected]
Subject:   Print Server protocol specs
I would like some information on Print Servers under the TCP/IP
protocol suite. Are there any standard specs or protocols for print servers?

I have looked at the RFC index at SRI-NIC and there does not seem to be any
RFC for Print Servers. Terminal servers support RS232 printers - does that mean
that "lpr" on the Unix machines simply use "telnet" connections to dump the
file to the terminal server printer port? How about the job header (owner of
the job, file name, etc) and the page headers (file name, page numbers)?

If any of you out there know of any specs that could
help me out, I'd really appreciate your input.

Diptish Datta          (703) 378-7600            [email protected]
Secure Products
Verdix Corp.   14130-A Sullyfield Circle; Chantilly; VA 22021
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 19:12:05 EDT
From:      [email protected] (Rob Coltun)
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re: router requirements (was: more to argue about)
John removed the hierarchical limitation early on. The reason being that
(as you said earlier) fixing the problems that can arise from non-contiguous
subnet masks should be in an RFC and not in a protocol spec.

---rob
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 15:18:38 GMT
From:      [email protected]  (Peter Weiss)
To:        [email protected]
Subject:   Re: IP-routers vs SNA-bridges
Please, please don't forget the issues of host-initiated SNA print
over the IP network, when deciding on your approach.

/Pete
--
Peter M. Weiss                   | [email protected] or @vm.psu.edu
31 Shields Bldg (the AIS people) | 2 4 6 8 We don't want to calculate!
University Park, PA USA 16802    | Disclaimer -* +* applies herein
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 21:05:59 GMT
From:      bacc[email protected]decwrl.dec.com  (Fred R. Goldstein)
To:        [email protected]
Subject:   Re: KA9Q (NOS) and HOSTS.NET
In article <[email protected]>, [email protected] (Jose Angel Vela Avila) writes...

>   But I have another problem, if I tell to NOS that route all packet to a 
>    subnet 131.178.10.x with the following command :
>    route add 131.178.10/24  Interface
>   It says me : Unknown Host 131.178.10/24    Why ?

I think that you have to encapsulate dotted-decimal addresses inside
brackets, thus:  [131.178.10.0]/24

Otherwise it looks in the hosts/domains table for a host whose actual
name (not numeric address) is 131.178.10/24.
BTW there's a little C program floating around to convert the hosts
table to the domains format.  Someone might want to put it on the net.
    fred k1io
---
Fred R. Goldstein   [email protected] 
                 or [email protected]
                    voice:  +1 508 486 7388 
-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 21:54:31 GMT
From:      [email protected]  (Jeffrey Mogul)
To:        [email protected]
Subject:   Re: Netmasks
In article <[email protected]> [email protected] writes:
>Which RFC(s) explains the interpretation and usage of netmasks?

The basic theory is set out in RFC950.

-Jeff
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jun 90 08:10:51 EDT
From:      MM438 <MEYSTMA%[email protected]>
To:        Tcp/Ip <[email protected]>
Subject:   Unsub
I am truly sorry to disturb and distribute this message to the entire
list, but requests to tcp-ip-request seem to go unheeded, and my
mail queue is constantly filled with messages from tcp/ip that I'm not
ready for. Can someone out there sign me off the list? thanks -MM438
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 04:31:35 GMT
From:      [email protected]  (jaleel ihsan)
To:        [email protected]
Subject:   Re: How long before I can reopen a closed socket?
In article <[email protected]>, [email protected] (Steven Bellovin) writes:
> don't change.  However, the kernel will not let you bind even a
> server port if any TCBs exist with the same <localhost,localport>
> portion, even if all of the others have <remotehost,remoteport>
> filled in.  You can override this via setsockopt() with the
> SO_REUSEADDR option.  Inetd does exactly that.

If I use the SO_REUSEADR option and have two servers listen'ing
(with the same <locahost, localport> in the under-specified TCB),
who is going to get the connection ? !!!

Jaleel
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 04:57:49 GMT
From:      [email protected]  (jaleel ihsan)
To:        [email protected]
Subject:   Re: How long before I can reopen a closed socket?
In article <[email protected]>, [email protected] (Lars Henrik Mathiesen) writes:
> a socket has two address/port pairs, one local and one foreign.
> Bind(2) only sets the local part, so that the socket will accept
> connections from any client. (Each client uses connect(2) to set the
                   ^^^^^^^^^^
> foreign part on its socket and make a connection).

Can a server specify the remote address/port as well so that connect
request is accepted from that client only.  If yes how ?  Design
considerations require that I have a dedicated server preconfigured
(to providing the same service) to a specific client (there is a limited
limited number of clients).

Thanks in advance.

Jaleel
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 07:05:26 GMT
From:      [email protected]LOOM-BEACON.MIT.EDU
To:        [email protected]
Subject:   Wanted: Source for TCP/IP for AT&T 3B15
G'Day

We have just aquired a AT&T 3B15 minicomputer running Unix System V.2.
Our campus network is based on TCP/IP and we would like to connect the
3B15 to it.  I have been told that there is a possiblity that the CMU 
TCP/IP may be able to be compiled for this machine.  Can anybody tell
me who I would have to contact to confirm this information?  Secondly, 
is there anybody who also has one of these machines that have attempted
to do likewise?

Don Griffiths
Curtin University
Western Australia
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jun 90 17:28:51 PDT
From:      [email protected] (Kenneth Adelman)
To:        [email protected]
Cc:        [email protected]
Subject:   Re: [[email protected] (Michael E. Pare): Terminal Server Response Time]
> The problem of support lies in the response time of any TCP/IP server to
> various control signals under VMS due to the packet sizing.  Under LAT,
> which is specifically designed to work only with LAT hosts on the same
> local network, you get immediate response to such control characters as
> ^C or ^Y, etc.  With TCP/IP, when you issue a ^C or ^Y you must wait
> until the packet(s) already sent by the host roll through your screen
> before you see the break or interrupt take effect (say for example you
> are typing a file to your screen).  I can control the situation with ^C
> because I can set it as a break character on the server and the server will
> react to it by issuing an inband or out-of-band break and flush the packets.
> However, with ^Y, which in this example would stop the output until you
> issue a continue command on the host, you must wait for an additional few
> screens of output to go by before it stops.  If you set this as the break
> character to flush packets, the output will stop immediately but when you
> do a continue you will have lost a lot of data.

> The hosts in my situation are various DEC machines running under VMS and
> using DEC's UCX TCP/IP software.  DEC has not shown us a way to change the
> TCP packet size.  Ideally I think we need to reduce the Telnet packet size
> to provide better response time for terminals without affecting the FTP
> transfer rate.  I also have this problem on one host running Wollongong
> TCP/IP software.

> Has anybody out there run across this situation and been able to resolve it?
> I even asked 3COM about it since they have VAXes at their site but they
> could not provide me with a solution.  I would appreciate any help with this
> so I can decide whether to go ahead with installing additional TCP/IP
> servers or have to go with LAT servers to provide the proper response time.

    Yes, a number of MultiNet customers have made the same complaint.
In our next release we provide a way of reducing the buffer size.  The
real problem lies in the VMS terminal driver which doesn't always
notify the VMS terminal port driver (i.e., the TELNET server) that an
'abort' should occur.  The best workaround would be to configure your
TELNET server to send an IAC AO after ^C or ^Y, or to use timing-mark
flushing when the user types these characters.

						    Ken
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 12:10:51 GMT
From:      [email protected] (MM438)
To:        comp.protocols.tcp-ip
Subject:   Unsub
I am truly sorry to disturb and distribute this message to the entire
list, but requests to tcp-ip-request seem to go unheeded, and my
mail queue is constantly filled with messages from tcp/ip that I'm not
ready for. Can someone out there sign me off the list? thanks -MM438

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 12:42:17 GMT
From:      [email protected]  (Larry Backman)
To:        [email protected]
Subject:   Is there a License server RFC?

Is there an RFC written for a License Server application.  I am looking
for something that would monitor and control the concurrent execution of
a single networked copy of any executable program.  I want to be able to
put an executable on a network drive, and control the number of people
using it at a single time.



					Larry Backman
					[email protected]
					uunet!interlan!backman
-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jun 90 16:52:37 EDT
From:      Bill Streilein <[email protected]>
To:        [email protected]
Hello,

I'm interested in finding out about various IP implementations.
Specifically, I'd like to find out how different implementations 
chose to organize the IP route information (i.e.  hash tables, 
balanced trees, etc.) and why.

If there's enough response, I'll post the results of the search.

Then again, maybe someone's already done this and all I need is a pointer
to the right doc.  :-).


Thanx in advance,
Bill Streilein
[email protected]
Wellfleet Communications, Inc.

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 00:52:24 -0700
From:      [email protected] (Steven M. Schultz)
To:        [email protected], [email protected]
Subject:   Re: Knowledge-is-Power Department
> From: [email protected]
> 
> The problem stemmed from a bug in their mail software that caused all mail to
> start bouncing when a partition filled up. However the bounced mail was not
> bounced correctly....
> Since the problem began on Friday and there is noone in the office at Portal
> over the weekend, it took a while for the problem to be corrected.

	there's no one there on weekends?  or no one monitors the system
	after 1700 Friday?  at a "major relay station" no less? gads zooks.
	one would think a partition filling up would be noticed well in
	advance of "der woche ende", or that the real "hackers" would 
	keep an eye peeled for system misbehaviour in general.

	Steven
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 13:27:32 GMT
From:      [email protected]  (Pieter Venemans)
To:        [email protected]
Subject:   SLIP and T2000 modems
I am trying to use two Telebit T2000 modems for a SLIP link between my
SUN at home and a SUN at the university. It works, but the performance
is quite disappointing. With plain 2400 baud modems, I get a transfer
rate of 0.21 kbyte/sec with ftp (quite good), but with the T2000s it is
only 0.65 kbyte/sec. I know, PEP is not ideal for this application and
it would be better to use V32 full-duplex modems, but these T2000s are
the only ones we have.

Does anyone have an explanation for this bad performance? Is there
any way to tune TCP, SLIP or the T2000s (secret registers, maybe?)
for a better throughput?

Here are the details: SUN-3/60 with SunOS 4.0.3, SUN-2/50 with SunOS
3.5 and 4.3-tahoe BSD TCP, Compressed header SLIP, very clean (local)
telephone connection. 

Thanks!
--
Pieter H.A. Venemans, Delft University of Technology, the Netherlands
DOMAIN: [email protected]         BITNET/EARN: [email protected]
UUCP:   ...!mcsun!hp4nl!dutrun!dutetvg!pieter     VOICE:  +3115786272
-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 15:06:25 GMT
From:      [email protected]  (Ian J Spare)
To:        [email protected]
Subject:   UUCP over TCP Problems
Our organisation is currently evaluating local area networks. We have the 
following equipment :

      2 x NCR Tower 32/400 running SysV R3 Unix and Win-TCP
      1 x NCR Tower 32/400 running SysV R2 Unix and Excelan TCP/IP
      Several PC'c Running PC/FTP and interdrive
      Various Terminal servers etc.

We have some problems with the boxes and wondered if anyone else had seen
similar or knew a solution.

Firstly, we have configured the two Rel 3 machines to talk to each other using
UUCP over TCP  , the normal file transfers work OK but a 'cu' to a machine will 
connect and instantly lose carrier and disconnect.

Secondly, we tried to get the Rel 2 machine using Excelan to talk to the WIN 
machines using UUCP over TCP , this was spectactularly unsuccessful !! The
best we got was the machine calling itself , handy :-) ??? The files were
setup as suggested in the Excelan manual , this seems to document an earlier
release of UUCP than Rel 2 NCR's actually have.

Finally , I am very interested in any info. that people have about SNA gateways
on TCP LANS.  We have been unsuccessful in locating a suitable gateway with the kind of functionality we require. We have been offered gateways with LU1 and 
3270 capablility but none ( so far :-) ! ) with LU6.2 . The situation I envisage
is being able , from a Unix host, talk LU6.2 through a gateway to an IBM host.
I am quite happy for any ( potential ) suppliers of this sort of kit to
contact me directly.

Thanks In Advance ,
Ian Spare

--
  Ian Spare                         |
  iT                                |        E-mail : [email protected]
  Barker Lane                       |        BANG-STYLE : ......!ukc!ukpoit!ian
  CHESTERFIELD S40 1DY              |        VOICE : +44 246 214296
  Derbys, England                   |        FAX   : +44 246 214353
--------------------------------------------------------------------------------
      iT - The Information Technology Business Of The Post Office
-----------------------  In Tune With Technology -------------------------------
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 15:06:57 GMT
From:      [email protected]sd.edu  (Paul J. Wagner)
To:        [email protected]
Subject:   Backups over tcp-ip connection
A friend of mine has a Vaxstation running Ultrix on a tcp-ip network
with a Vax running VMS.  He's interested in the possibility of backing
up the Ultrix station on the Vax over the network.

Is anyone doing this sort of thing?  Any pointers on what software would
be necessary or on what other requirements exist?  Is this even possible?

Any and all information would be much appreciated - please respond by
email and I'll summarize to the net.

Thanks much,

Paul
-- 
* Paul J. Wagner                Internet - [email protected]              *
* Computer Science Department   UUCP	 - ...!rutgers!umn-cs!wagner      *
* University of Minnesota       or, 120 S. Michigan, Eau Claire, WI 54703 *
*     "think globally, act lexically"                                     *
-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 15:14:26 GMT
From:      [email protected]
To:        [email protected]
Subject:   Re: Knowledge-is-Power Department
In article <[email protected]>, [email protected] (Hilarie K. Orman) writes:
> My sense of frustration at the portal fiasco was alleviated this
> evening when I glanced at a recently obtained copy of "!%@:: A
> Directory of Electronic Mail Addressing and Networks", by Donnalyn
> Frey and Rick Adams, and learned that Portal is a General Subscription
> Service based in Cupertino, offering UUCP and USENET feeds.  Its voice
> number is 408-973-9111, and it takes email at [email protected]  This
> sort of information suggests more constructive activities to take
> against email blizzards than sending mail into the fray and becoming
> part of the problem.  Like this note.  I hope no one has to see it
> more than once.
 
I spoke with the management of portal Monday morning. I was told that I was
about the hundredth caller.

The problem stemmed from a bug in their mail software that caused all mail to
start bouncing when a partition filled up. However the bounced mail was not
bounced correctly. It appears that it was resent like a new message with a new
ID.

Since there was a subscription to info-tcp-ip involved, all of the mail was
re-posted to comp.protocols.tcp-ip...over and over again.

The folks at portal were most apologetic and by the time I called the problem
was already fixed. Hopefully they will find the problem in the mailer and get
it fixed so that the problem will not recur next time a disk gets full.

Since the problem began on Friday and there is noone in the office at Portal
over the weekend, it took a while for the problem to be corrected.

While !%@:: was outdated before it every hit the streets, it is still a
valuable reference for most any mail system operator. But I found Portal by the
use of the whois server at the NIC. It's another very useful tool for those
with Internet connectivity.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: [email protected]
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 17:55:04 GMT
From:      [email protected]  (Alfonso Jesus Trevino Cantu)
To:        [email protected]
Subject:   RPC's for Macintosh
Does anybnody know of a product that lets a C programmer in Mac make Remote
Procedure Calls? By the way, I'm also interested in products that implements
NFS in Macs.

Thank you
Alfonso
-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 18:02:41 GMT
From:      [email protected]  (Dave Carter)
To:        [email protected]
Subject:   Re: Networking RT11
thanks to all of you who responded.  it appears that Process Software
has tcp/ip for rt11.  i will contact them.

						- dave
[email protected]
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 19:04:51 GMT
From:      zaphod.mps.ohio-state.edu!samsung!cs[email protected]tut.cis.ohio-state.edu  (Rob Knauerhase)
To:        [email protected]
Subject:   TCP/IP for Ungermann-Bass cards?
After repeated assurances that the only TCP/IP protocol package for the
Ungermann-Bass NIUPC card was from Ungermann-Bass, and that it was, well,
kind of a minimalist statement in networking, I recently heard that
_someone_ else (possibly FTP Software) were now supporting the card.

    I looked several weeks ago for a packet driver from a couple
distribution sites and was disappointed.  Does anyone know of a TCP/IP
package for this card, or better yet a packet driver for it?

Thanks 10^6.
Rob Knauerhase
+-------------------------------------------------------------------------+
|Robert C. Knauerhase                          [new alumnus]              |
|   [email protected],[email protected] | Case Western Reserve University |
|   [email protected]          | NASA Lewis Research Center      |
+---------------------------------------+---------------------------------+
|   "Computers are different from telephones.  Computers do not ring."    |
|                    -- A. Tanenbaum, "Computer Networks", p. 32          |
+-------------------------------------------------------------------------+
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 20:34:46 GMT
From:      [email protected]  (Mick Scully)
To:        [email protected]
Subject:   OSI/NM - Information Anyone?
The trade rags have indicated that the OSI/NM group has released their
first draft of a network management spec (with MIB).

Does anyone know if the spec and MIB is online anywhere?

Thanx in advance!

Mick
-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 21:35:27 GMT
From:      [email protected]  (Mike Black)
To:        [email protected]
Subject:   MNP to Telebit locks up
Can anyone tell me why my MNP Class 9 modem locks up a Telebit Trailblazer?
When they connect the immediately hang-up and then the Telebit won't generate
and answer carrier until reset.  What gives?  This has happened on two 
different MNP modems with the same Trailblazer.  Any switches that can be
set to prevent this from happening?
Please e-mail replies and I will summarize.
Mike...
--
-------------------------------------------------------------------------------
: usenet: [email protected]   :  land line: 407-494-5853  : I want a computer:
: real home: Melbourne, FL     :  home line: 407-242-8619  : that does it all!:
-------------------------------------------------------------------------------
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 04:07:28 GMT
From:      [email protected]  (Tim Cook)
To:        [email protected]
Subject:   Need help configuring SLIP interface under DYNIX
I have a problem using a Sequent as a gateway to other networks via SLIP.

I have the following:

1.  One class B network, which is our local network.

2.  One class C network, which is the SLIP network.

3.  One Sequent, running DYNIX 3.0.12, on both networks.

The SLIP network is a sub-net of the class B network that connects to its
remote end.  I used the following commands to configure the SLIP interface,
`sl0':

	% ifconfig sl0 x.y.z.2 x.y.z.1 netmask 0xffffff00
	% route add default x.y.z.1 1

The route command sets up a default route, so that all non-local traffic is
directed through the SLIP link.  I'm sure this is something that has been
done many times before.

The problem is, some routing works, some doesn't.  From our local host that
has the SLIP interface, I can communicate with the host on the other end of
the SLIP network, and one other host on the class B net that the SLIP net
is a sub-net of.  However, people at sites on the remote class B net, and
another net connected to that net tell me they can communicate with hosts
at our site, and local hosts that are not the host with the SLIP interface
can communicate with remote hosts.

Being nothing much of an expert at IP, I have reached a state of
bewilderment.  If anyone out there can offer any clues as to
what/why/how-to-fix, I would be grateful.
-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Thu 21 Jun 90 11:44:18-PDT
From:      [email protected] (L. Stuart Vance)
To:        [email protected]
Cc:        [email protected]
Subject:   Re: Backups over tcp-ip connection
>Date: 20 Jun 90 15:06:57 GMT
>From: [email protected]sd.edu  (Paul J. Wagner)
>Organization: University of Minnesota, Minneapolis - CSCI Dept.
>Subject: Backups over tcp-ip connection
>
>A friend of mine has a Vaxstation running Ultrix on a tcp-ip network
>with a Vax running VMS.  He's interested in the possibility of backing
>up the Ultrix station on the Vax over the network.
>
>Is anyone doing this sort of thing?  Any pointers on what software would
>be necessary or on what other requirements exist?  Is this even possible?

Our MultiNet TCP/IP for VMS package supports an RMT (Remote MagTape) server,
allowing you to use the UNIX rdump and rrestore utilites to backup/restore
files from your ULTRIX box to your VMS system.  Please drop me a note if you
would like any additional information/details.

Regards,

L. Stuart Vance
TGV, Inc.
-------
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 10:20:44 EDT
From:      Charles Lynn <[email protected]>
To:        Kenneth Adelman <[email protected]>
Cc:        [email protected], [email protected]
Subject:   Re:  [[email protected] (Michael E. Pare): Terminal Server Response Time]
FYI, another thing that the old TOPS20 code did was to inform TCP
of the terminal's baud rate. TCP then timed the generation and
transmission of packets to match that rate; the result was a
"much more responsive" system.
-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 10:20:57 EDT
From:      "Mr. Donald W. Garner (CADIG  STAFF) " <[email protected]>
To:        [email protected]
Subject:   UUCP and USENET Feeds
Are there any organizations, other than UUNET Communications and PSI,
that provide UUCP and USENET feeds to the VA/DC/MD area?

Thanks - Don Garner ([email protected])
-----------[000398][next][prev][last][first]----------------------------------------------------
From:      [email protected]
To:        [email protected]
Cc:        
Subject:   Re: Print Server protocol specs
>I would like some information on Print Servers under the TCP/IP
>protocol suite. Are there any standard specs or protocols for print servers?
>
>I have looked at the RFC index at SRI-NIC and there does not seem to be any
>RFC for Print Servers...

The finalized draft version of the LPR RFC will be appearing on
[email protected] around July 1st.  It should then
be available as an RFC shortly after the July/August IETF.

enjoy,
leo j mclaughlin iii
Chair, Network printing WG
[email protected]

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 12:13:41 GMT
From:      [email protected]tut.cis.ohio-state.edu  (Larry Backman)
To:        [email protected]
Subject:   Re: Motrning of the parsinf of the [email protected]
In article <[email protected]> [email protected] writes:
>In article <[email protected]>, [email protected] (Joe Ragland( writes:
>> Yea, maybe in good h`m radio DXpedithnn rtyle,  Dan Lynch could hssud a
>> certifhcatd for exbhanfing mail with a net 10 host at Interop?
>
>I'm befinnhng to like this ide` more and more...
>
>It could also be fun to five the shov backbond routers "historically
>significant" IMP nales, so that you could do tracernutes and so on...
>
>--
>Amanda Walker, InterCnn Systems Corporatinn
>--
>"Y'knov, you can't have, lhke, a light, without a dark to stick it in...
> Ynu know what I'm sayin'>"     -,@rln Guthrid

I think Portal ought to turn on checksums in addition to their other
problems......
-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 16:17:18 EDT
From:      [email protected]  (James B. Van Bokkelen)
To:        zaphod.mps.ohio-state.edu!samsung!cs[email protected]tut.cis.ohio-state.edu  (Rob Knauerhase)
Cc:        [email protected]
Subject:   Re: TCP/IP for Ungermann-Bass cards?
We support the two U-B 'dumb' cards, sometimes known as the NIC/PC
(supported for about two years) and the NIC/PS2 (in beta last week).
We don't support the NIU (smart) cards, unless U-B or someone else
has recently developed either a Packet Driver or an NDIS driver for
them.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 14:26:26 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!sa[email protected]ucsd.edu  (Evan Ross)
To:        [email protected]
Subject:   Looking for SNMP parser
	Can anyone point me towards a publicly available SNMP parser?
	The RFC's are quite thorough in terms of abstract definitions,
	but lacking in terms of practical information.


	Evan Ross,	{think,xylogics}!signet!evan, or junkyard!evan
-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 14:53:05 GMT
From:      [email protected]  (Ralph Nicovich)
To:        [email protected]
Subject:   MX records

I have a problem with SMTP on campus. It has to do with MX records.
If a user sends mail to a place that uses MX records, so that the
mail address is not a real host name, the mail bounces.

This occurs with AIX machines as well as SUNs. I located a fix for
68000 based SUNs, and am told that the next release of AIX will
fix this.

Does anyone have a fix for SUN 386i's ?
Are there any public machines that mail can be sent thru, that
will deliver the mail for my machines ?
Are there any "tricks" that work for the general case of a machine
that does not support MX records ?

Thanks for any help.
Ralph Nicovich
Network engineering
Cal Poly State University.
[email protected]
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Thu 21 Jun 90 18:53:28-EDT
From:      Dan Lynch <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   re: How long before I can reopen a closed socket?
Well, I tried to send this reply to the originator and not the whole list,
but the address was just too much to swallow!
Dan
                ---------------

Mail-From: OPERATOR created at 21-Jun-90 17:50:36
Date: Thu 21 Jun 90 17:50:36-EDT
From: The Mailer Daemon <[email protected]#Internet>
To: [email protected]#Internet
Subject: Message of 21-Jun-90 00:28:02

Message failed for the following:
[email protected]#Internet: 554 <[email protected]>... Unknown uucp host sun-barr
	    ------------
Date: Wed 20 Jun 90 21:28:01-PDT
From: Dan Lynch <[email protected]>
Subject: Re: How long before I can reopen a closed socket?
To: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

Jaleel,  You can certainly build a server to do exactly as you
described.  It would only listen for specific ports from specific
addresses.  The algorithm for selecting port numbers for TCP and
UDP that are not the "well known port numbers" is entirely up
to the hosts in question.  You are looking for a way to restrict
service and this is one (weak) way to do so.  "Weak" in the security
sense.  

Dan
-------
-------
-------
-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 15:10:48 GMT
From:      swrinde!cs.utexas.edu!sdd.hp.c[email protected]ucsd.edu  (Johnny zweig)
To:        [email protected]
Subject:   Re: TCP/IP for Ungermann-Bass cards?
I could have sworn that NCSA Telnet supports the Ungermann-Bass card, but
that is based on some driver code I looked at three years ago that said
"change this to a 0x06 for Ungermann-Bass" or something like that.

It's worth looking into, however.  Anonynmous ftp to zaphod.ncsa.uiuc.edu
and a few minutes' poking around should tell you.

-Johnny Possibly
-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 18:45:11 GMT
From:      [email protected]  (Bruce Munro)
To:        [email protected]
Subject:   Vendor numbers et al.
Not strictly IP oriented, but I know people round here are pretty
knowledgeable.

What I'm looking for are the latest copies of a group of documents
that list which ethernet numbers have been allocated to which vendors,
packet type numbers, and so on. I've got a rather ancient copy, but it
doesn't have the info I need.

Any help/pointers appreciated.

Thanks,
-- 
Bruce Munro.  <[email protected]> || ...!mcsun!ukc!stc!bruce
STC Telecommunications, Oakleigh Rd South, London N11 1HB. 
Phone : +44 81 945 2174 or +44 81 945 4000 x2174
"There are no strangers, only friends we don't recognise" - Hank Wangford
-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jun 90 08:45:04 -0700
From:      Marshall Rose <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   Re: Looking for SNMP parser
Get a copy of RFC1147 to find out about 2 of the 3 public domain SNMP
implementations.

/mtr
-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 21:49:45 GMT
From:      [email protected]  (Todd Welch)
To:        [email protected]
Subject:   Re: Motrning of the parsinf of the [email protected]
        Folks -

        oh usre, go ahd `nd lauph, i membre when thissss response <ACK>
        was semt to a query about runnig XNS adn TCP over <ACK>[email protected]<ACK> teh
        s`me cococoax. i laupheb then too, net-10 real foonly humour.

        BTW, wehres the crucible feed @?

        -todd

        [email protected]
        Sterling Software

        -       its only that the past has lighted our way              -
        -=      no one survived the imp route jabber of late '70s       +-)
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jun 90 09:28:34 PDT
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re:  Vendor numbers et al.
Bruce Munro:

A reasonably complete set of Ethernet nembers is included in the "Assigned
Numbers" memo, RFC-1060.

--jon.
-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 02:58:08 GMT
From:      [email protected]  (Patrick Herlihy)
To:        [email protected]
Subject:   Re: TCP/IP for Ungermann-Bass cards?
In article <[email protected]>, [email protected] (Johnny
zweig) writes:
> Path:
metro!munnari.oz.au!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr
.columbia.edu!IDA.ORG!zweig
> From: [email protected] (Johnny zweig)
> Newsgroups: comp.protocols.tcp-ip
> Subject: Re: TCP/IP for Ungermann-Bass cards?
> Message-ID: <[email protected]>
> Date: 21 Jun 90 15:10:48 GMT
> References: Available upon request. :)
<[email protected]>
> Organization: IDA, Alexandria, VA
> Lines: 9
> 
> 
> I could have sworn that NCSA Telnet supports the Ungermann-Bass card, but
> that is based on some driver code I looked at three years ago that said
> "change this to a 0x06 for Ungermann-Bass" or something like that.
> 
> It's worth looking into, however.  Anonynmous ftp to zaphod.ncsa.uiuc.edu
> and a few minutes' poking around should tell you.
> 
> -Johnny Possibly

NCSA Telnet 2.3 supports U-B PCNIC card, but not PCNIU (we have a mixture of
both.

Patrick Herlihy
-----------[000410]