The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for October 1988 (424 messages, 217715 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/10.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Oct 88 04:15:10 EDT
From:      Chris Torek <chris@gyre.umd.edu>
To:        eagle_snax!geoff@decvax.dec.com, tcp-ip@sri-nic.arpa
Subject:   Re:  SLIP MTU "violation" - does anyone? does anyone care?
	From: eagle_snax!geoff@decvax.dec.com (R.H. coast near the top)

	... I found that the "generic" SLIP driver cares not a jot or a
	tittle for such things, and will cheerfully keep stuffing an
	infinite amount of unterminated data into the mbuf chain. 

	My question is, will enforcing the 1006 byte MTU break anything
	out in netland (other than the already-identified buggy client,
	now fixed)?

I am not sure what the `generic' SLIP driver is supposed to be.  4.3BSD
keeps a count of input bytes, and discards an input packet (with an
`input error') if the count goes over SLMTU.  I vaguely remember
installing such code in the original 4.2BSD SLIP driver, so it may not
appear in Rick Adams's version.

Given that 4.3BSD already enforces this limit, the answer seems to be `no'.

Chris
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 88 04:43:32 GMT
From:      rdp@pbseps.UUCP (Richard Perlman)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   Telnet to a tcp port other than 23


...
I am looking for a telnet implementation that allows connection
to a tcp port other than 23 (the default port for telnet).

I have tried both Sun's and NCSA's products, but neither has a
provision to specify a port other than 23.

I know this is possible, since the telnet implementation on our
Sequent (UNIX) Symmetry has this feature.

In case you are wondering why this feature is desireable:
we have an async server that allows each port to be configured
with a unique tcp port address (>1025).  With out being to
specify the port all "calls" go to the default port 23.

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

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 88 04:54:46 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP support for 3C505 card

In article <1936@turnkey.TCC.COM> jack@turnkey.TCC.COM (Jack F. Vogel) writes:

   In article <157@amtfocus.UUCP> irab@amtfocus.UUCP (Ira Brenner) writes:
   >support [for] the 3C505? 

   Ira,	As far as I know the current version of KA9Q will support the
   3Com board,
No, the built-in support is for the 3Com 3c501, not 3c505.  However, the
current version of KA9Q supports the FTP Software packet spec, so if anyone
is willing to write a driver, they can use KA9Q.

   Both of these packages [KA9Q's NET and MIT's PC/IP] are public domain.
KA9Q is certainly NOT public domain.  KA9Q is freely copyable
for non-commercial and non-governmental purposes.  KA9Q is explicitly
copyable by radio amateurs and educational institutions.  MIT's PC/IP
is also not public domain, but instead is freely copyable so long as
the copyright message remains intact.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
To surrender is to remain in the hands of barbarians for the rest of my life.
To fight is to leave my bones exposed in the desert waste.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 88 05:58:33 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   Re: Telnet to a tcp port other than 23

In article <282@pbseps.UUCP> rdp@pbseps.PacBell.COM (Richard Perlman) writes:
 >I am looking for a telnet implementation that allows connection
 >to a tcp port other than 23 (the default port for telnet).
 >
 >I have tried both Sun's and NCSA's products, but neither has a
 >provision to specify a port other than 23.
 >
 >Richard Perlman * pbseps!rdp@PacBell.COM || {ames,sun,att}!pacbell!pbseps!rdp

What do you mean Sun's telnet does not allow this.  It sure does.
Just type:
	telnet <machine> <port>
where <port> is either a number or a name mentioned in /etc/services;
i.e. telnet <machine> mail

My sun man page looks like:

TELNET(1C)                USER COMMANDS                TELNET(1C)

NAME
     telnet - user interface to a remote system using the  TELNET
     protocol

SYNOPSIS
     telnet [ host [ port ] ]
     ........

Don't know about NCSA, though I would assume it also has this ability.

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

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Oct 88 13:24:47 PDT
From:      ucla-an!stan@ee.UCLA.EDU (Stan Stead)
To:        tcp-ip@sri-nic.arpa
Cc:        byron@ee.UCLA.EDU
Subject:   pop2 and PC-NFS Lifeline

After months of work and chasing down mulitple bugs we have brought up
PC-NFS v 3.0.  Unfortunately, after we installed Lifeline (the pop2 client)
for a PC, we find that it is NOT a TSR and thus has limited (if any real)
usefulness.  Has anyone created a pop2 client for the PC that will coexist
with PC-NFS and remain as a TSR so that mail delivery is always available
and relatively transparent?

Also, just as a general comment is everyone having a difficult time getting
SUN to support PC-NFS?
	Thanks in advance.

Stan

Stanley W. Stead
UCLA School of Medicine / Dept of Anesthesiology
BELL: (213) 206-6238
ARPA: ucla-an!stan@ee.UCLA.EDU
UUCP:  {trwrb|ucla-cs|cepu}\
                            !ucla-an!stan
UUCP: {ihnp4|decvax}!hermix/
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 88 22:30:44 GMT
From:      daveb@geaclib.UUCP (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Re:  Graziano's Streams Query


In article <8809260302.AA11541@ucbvax.Berkeley.EDU> dcrocker@TWG.COM (Dave Crocker) writes:
| One of the emerging major benefits of Streams is its utility in a
| multi-processor environment.  Properly implemented, streams modules may
| operate in DIFFERENT address spaces.  The only shared memory that is needed
| is for message-passing and data-buffers.
 
From article <1247@xyzzy.UUCP>, by thadani@xyzzy.UUCP (Usenet Administration):
|      This suggests that a Streams module may be written in
|      a special way to run in a multi-processor environment, whereas
|      perhaps it is the implementation of the Streams facility that would 
|      most require careful design for multi-processor operation.  

  Well, you can have it either way.  If your suppliers' streams
modules are for a standard uniprocessor configuration, one can write
a special one to transfer data to a separate device.  This might be a
good way of bootstrapping a FEP (front-end processor).
  Conversely, your supplier may use a bootstrap of this sort to
develop a cross-machine streams facility.  It is not immediately
obvious whether such a facility would be transparent or visible to
the streams user, although it would almost definitely be visible to
the system administrator...



-- 
 David Collier-Brown.  | yunexus!lethe!dave
 Interleaf Canada Inc. |
 1550 Enterprise Rd.   | HE's so smart he's dumb.
 Mississauga, Ontario  |       --Joyce C-B

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 88 23:53:36 GMT
From:      rdp@pbseps.UUCP (Richard Perlman)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   Re: Telnet to a tcp port other than 23

In article <282@pbseps.UUCP> I wrote:
>I am looking for a telnet implementation that allows connection
>to a tcp port other than 23 (the default port for telnet).
>
>I have tried both Sun's and NCSA's products, but neither has a
>provision to specify a port other than 23.

And in article <23648@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) answers:
>What do you mean Sun's [UNIX] telnet does not allow this.  It sure does.
>Just type:
>	telnet <machine> <port>

And he is, of course, correct.  It was my error in not clearly 
explaining the problem.  I meant telnet for *MS-DOS*, as 
distributed with PC-NFS.  Now that that's clear, any other ideas.

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

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 88 03:24:03 GMT
From:      emv@mailrus.cc.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   Re: Telnet to a tcp port other than 23

In article <284@pbseps.UUCP> rdp@pbseps.PacBell.COM (Richard Perlman) writes:
>In article <282@pbseps.UUCP> I wrote:
>>I am looking for a telnet implementation that allows connection
>>to a tcp port other than 23 (the default port for telnet).
>>

ka9q lets you do that.

--Ed

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Sun, 02 Oct 88 09:21:13 CDT
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Subnet questions.
BACKGROUND:
We are implementing a campus-wide network which will be a bridged
ethernet supporting TCP/IP.  The only router in the network is a P4200
which is our SURANET gateway.  We have a class B internet address, 130.18.
It was suggested that we assign our campus IP addresses in a "subnetted
fashion", even though we will not be using routers to physically subdivide
our network.  Typically, we will allocate one subnet per building, with a
MAC level bridge connecting each building to the backbone.

QUESTIONS:
Does the suggestion that we assign IP addresses in a "subnetted fashion"
imply that we should also assign a subnet mask of other than 255.255.0.0?
If we do this, it means that the gateway for most hosts on our campus net
will be on a different subnet than the host itself.  Is this legal?  Even
if it is legal, is this really what we want to do?  This would mean that all
intra-campus traffic between two different "pseudo-subnets" would have to
pass through the one P4200, even though normal ARP routing could be used.
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Sun, 02 Oct 88 18:29:51 -0700
From:      Marshall Rose <mrose@TWG.COM>
To:        two lists: ;
Subject:   Action item from Interop '88
Hi.  At Interop '88 last week, I was asked to drop a note to the TCP-IP
list describing my experiences in using TLI.  In particular, I had
commented that there were a couple of features of TLI that I wasn't too
keen on.

At the time, I agreed to send the note to the TCP-IP list, but since I
was using TLI to do OSI programming, this probably isn't the right
forum.

So rather than bother the whole list with what may turn out to be a
detailed discussion, I'm opting to move it to the ISO list.  If you were
expecting to see this discussion on TCP-IP, switch to ISO instead.  The
next message on the ISO list starts it off.

Thanks,

/mtr
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 88 14:21:13 GMT
From:      RACKLEY@MSSTATE.BITNET (Mike Rackley)
To:        comp.protocols.tcp-ip
Subject:   Subnet questions.

BACKGROUND:
We are implementing a campus-wide network which will be a bridged
ethernet supporting TCP/IP.  The only router in the network is a P4200
which is our SURANET gateway.  We have a class B internet address, 130.18.
It was suggested that we assign our campus IP addresses in a "subnetted
fashion", even though we will not be using routers to physically subdivide
our network.  Typically, we will allocate one subnet per building, with a
MAC level bridge connecting each building to the backbone.

QUESTIONS:
Does the suggestion that we assign IP addresses in a "subnetted fashion"
imply that we should also assign a subnet mask of other than 255.255.0.0?
If we do this, it means that the gateway for most hosts on our campus net
will be on a different subnet than the host itself.  Is this legal?  Even
if it is legal, is this really what we want to do?  This would mean that all
intra-campus traffic between two different "pseudo-subnets" would have to
pass through the one P4200, even though normal ARP routing could be used.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 88 15:02:37 GMT
From:      guru@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   retry




------- Forwarded Message

To: "David Cheriton" <cheriton@pescadero.stanford.edu>
cc: tcp-ip@sri-nic.ARPA
Subject: Re: ST in Gateways 
In-reply-to: Your message of Thu, 29 Sep 88 23:01:39 -0700.
             <8809300601.AA13414@Pescadero> 
Date: Fri, 30 Sep 88 13:34:21 -0500
From: Gurudatta Parulkar <guru>

  
>I regard ST as a rather unfortunate direction unless I am missing something.
>First, it totally violates the IP architecture by putting a network-oriented
>virtual circuit protocol in place of internetwork datagrams.  This has been
>done with almost no critical discussion and review outside of BBN to my
>knowledge.  Informal comments made to me suggest that there are about 3-4
>people in the known universe than understand ST, and not much enlightment
>to be gained from the confusing out-of-date RFC.
 
>Second, ST people seem to claim that there is some magic that makes it
>"more efficent" yet I know of no evidence to this effect. For example,
>Mackenzie's claimed advantage in multi-site delivery can be equally
>well provided (I conjecture) using the IP multicast extension.  And, as he
>admits, the ST guarantees are no guarantee.  I believe that IP multicast
>and a good TOS implementation could do just as well.

Well, I don't know the ST effort and BBN policies, but I want to
dispute your claim (I guess hypothesis) that the current IP
architecture is good for supporting applications such as video
conferencing and other such applications which need relatively high 
bandwidth and have real time constraints.

First of all, it is appropriate to describe my interpretation of
current IP architecture to put my thinking in perspective. 

In simple terms, the current IP architecture consists of a set of
gateways and networks which differ in their speed, access policies,
resource management, packet size and formats, etc. etc. Only thing
internet expects from the component networks is that they should try
to forward a minimum size datagrams and support an internet level
logical addressing scheme.  They are allowed to lose, resequence, and
duplicate datagrams and also they are not required to make any
guarantees about the performance. Gateways on the other hand are only
required to send the datagram towards the final destination. Again,
gateways are not required to do optimal routing in any sense. Of
course, TOS option allows an application to indicate what kind of
service it needs - optimize throughput, delay, and/or reliability.
However, the TOS is only a request to gateways which they can ignore,
or even worse, they may have no choice even if they understand the TOS
field.  (Well, that is my interpretation of the internet architecture,
and it is the right way to do things for the kind of objectvies it was
designed for as explained in Dave Clark's paper in recent SIGCOMM)

Now, in any internet, how can we make performance guarantees ? 

There are two approaches that can be used at the internet level to
make performance guarantees. The first approach involves resource
management on per "flow"(or quasi-reliable connection in my
terminology) basis and require some performance guarantees from
component networks. This approach requires that an application specify
its resource needs before starting to use them.  The application is
started or continued only if its needs can be met.  Once it starts,
mechanisms are provided to ensure that the component networks provide
the resources to the application and that the application does not use
more than its specified needs. Thus, if every application is using its
specified resources, an application can be sure to get its share of
resources, and thus, the expected performance.

The second approach is to over engineer the internet which means
over engineering component networks. If networks are sufficiently over
engineered, applications can be pretty much unconstrained and still be
sure that they can meet their resource needs, and thus get guaranteed
level of performance.   

Clearly, the current internet does not use the first approach and
depends on the second approach. However, it should be obvious that over
engineering a rapidly growing large internet is "unrealistic". And
therefore, I believe it is difficult, if not impossible, to
support applications which need performance guarantees or predictable
performance in the existing internet architecture. 

I argue that we can make much better performance guarantees if we use
combination of two approahces with emphasis on the first approach.
One of the ways to achieve this is to have an internet architecture
which consists of

- - a quasi-reliable connection-oriented (NOT THE SAME AS X.25 VIRTUAL
  CIRCUIT) internet protocol 

- - component networks which can do resource management on per
  connection basis or networks which help their directly connected
  gateways to do the resource management

- - component networks which can make performance guarantees using their
  resource management schemes  

I can elaborate on how to do this and why it can provide better
guarantees, but I am not sure if that is appropriate at this time.
However, the following comments are necessary:  

- - connection-oriented approach does not mean RELIABLE virtual
  connection where 
  you do hop-to-hop flow and error control. Thus, a connection only
  implies a pre-identified path and appropriate resources allocated on
  this path for the application. 

- - resources are not allocated on the basis of peak requirements but
  based on peak as well as average requirements. 

- - thus the key advantages of the quasi-reliable connection-oriented
  internet protocol is that it allows resource allocation on per
  connection basis, and as a result, can help us make performance
  guarantees and avoid congestion.

- - as the internet level protocol takes into account component networks'
  ability to make performance guarantees and their available resources,
  it can make better end-to-end performance guarantees. 

- - the connection-oriented model is inherently less flexible and less
  fail safe than the datagram model, but do you really need the
  flexibility or you need performance and performance guarantees. Note
  that now computer networks are not designed only for the department of
  defense. 

I hope this long note clarifies the following simple point:

"In the current internet architecture, it is difficult to make
performance guarantees. It would be easier to achieve this in an
internet which uses a quasi-reliable connection oriented internet
protocol and requires component networks to provide mechanisms for 
resource managment on per connection basis and to make performance
guarantees."

I hope this makes some sense.

- -guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
St. Louis MO 63130 
(314) 889-4621

------- End of Forwarded Message

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 88 15:07:29 GMT
From:      lotto@wjh12.harvard.edu (Jerry Lotto)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Need TCP/IP support for 3C505 card

In article <383@polyof.UUCP> john@polyof.UUCP ( John Buck ) writes:
>In article <157@amtfocus.UUCP>, irab@amtfocus.UUCP (Ira Brenner) writes:
 
>>                      Anyway, the real question is: are there any other 
>> software packages, possibly public domain, that will support the 3C505? 
 
>be much better!  We recently got a 3Com-523 (Micro-channel) card for
>our new PS2 system.  We had an AT with a 3C505, and upgraded.

upgraded?

>            I called FTP today, and they said that their latest product
>is "on hold".  She did not know "when it would be released for shipment."
>I find this very annoying, and hard to believe!  (How can they not
>know when a release is going to be ready?).

Try any number of problems, the printer didn't return the manuals on
time. Someone reported a bug that HAD to be fixed. An RFC was
released. etc... They do a pretty good job getting things out the
door, but they are a small company and cannot do many things in-house.

>plan on ordering it from them, however, be prepared to wait a loooooooooong
>time, as their shipment/release policies seem lacking.

I think that this posting was a knee-jerk reaction, extrapolating a single
data point! I have had nothing but good service from FTP. They are a damn
site smaller than the companies that they compete with, you can still
talk to the actual developers on the phone if you have to. It is a shame
that you had a bad experience, may I suggest (if you are in a rush to
get something working), that you call back and ask WHY things are on hold.
Perhaps you can get code sooner than you think.

>                                      FTP can be reached at: 617-868-4878

BTW, the 505 driver has been available for quite some time. This was the
original question. The fact that you were trying to get a 523 driver was
interesting, but had nothing to do with a response to the first posting.

Disclaimer -	These are my personal opinions, I do not represent Harvard
		in this posting. I do not hold stock in or work for FTP.
		I do know the crew over there pretty well, and have a lot
		of respect for what they can accomplish.
-- 
Gerald Lotto - Harvard Chemistry Dept.
UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto
ARPA:  lotto@harvard.harvard.edu

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 88 15:17:08 GMT
From:      vidya@eneevax.umd.edu  (Vidya Rajagopalan)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP references

Can anybody on this net suggest some references to TCP/IP ?
I am looking for some reading material regarding the protocols
and standards as well as implementational details. I am particularly
interested in a good introductory reference.

I am planning to write a term paper on the subject and would appreciate
any suggestions.
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 88 18:18:43 GMT
From:      yba@arrow.bellcore.com (Mark Levine)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   Re: Telnet to a tcp port other than 23

In article <284@pbseps.UUCP> rdp@pbseps.PacBell.COM (Richard Perlman) writes:
>explaining the problem.  I meant telnet for *MS-DOS*, as 
>distributed with PC-NFS.  Now that that's clear, any other ideas.

(Replied by e-mail, but this nails it down better:)

You can also try to get the PC/IP package from the MIT Laboratory for
Computer Science; last I knew they still were selling it, perhaps through
the microcomputer store at MIT.

Eleazor bar Shimon, once and future Carolingian
yba@sabre.bellcore.com

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 09:20:00 PST
From:      <art@acc.arpa>
To:        "ahill" <ahill@cc5.bbn.com>
Cc:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   re: SLIP MTU "violation" - does anyone care?
>From: "Alan R. Hill" <ahill@CC5.BBN.COM>
>
>Rick,
>	I'll probably regret this but I have to ask why you have the
>impression that the IMP will not accept messages exceeding 1006 bytes?
>The X.25 limit is 1024.  The 1822 limit is 8063 bits and the DDN
>X.25 Standard service limit is 8056 bits or 1007 bytes.  Can you
>shed some light on where the 1006 byte number originated?
>
>Thanks,
>Alan

Alan,

I suspect that it dates back to old 1822 interfaces.  As you indicated,
for 1822, the limit is 1007 whole bytes.  But interfaces like the LH-DH/11
were 16-bit word oriented and therefore had a limit of 1006 bytes.
(IMP padding still occasionally nailed drivers not expecting more data
coming in than could be sent out)


+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@acc.arpa>		720 Santa Barbara Street		|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+


-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 02:49:52 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP MTU "violation" - does anyone? does anyone care?

Please dont enforce the 1006 byte limit. It is a historical
curiousity that is still around because when I wrote the
original code, the IP fragmentation code of most
systems didnt work worth a damn. So, I made the MTU 1006
so it wouldn't fragment going through an IMP. If I didn't have
an IMP, I probably would have made it 1534 (or whatever the ethernet is)

--rick

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Oct 88 10:01:30 PDT
From:      lougheed@clash.cisco.com
To:        "Alan R. Hill" <ahill@cc5.bbn.com>
Cc:        Rick Adams <rick@seismo.css.gov>, eagle_snax!geoff@decvax.dec.com, tcp-ip@sri-nic.arpa
Subject:   Re: SLIP MTU "violation" - does anyone? does anyone care?
Alan -

Regarding 1822 numerology:

8063/8 = 1007.875, so 1007 bytes is possible, but 1006 is the largest even
byte count.  Our experience on the DDN is that most systems use 1006 bytes
as the MTU.  Attempting to use a larger MTU has given us headaches,
especially with some Berkeley-derived systems.  Invoking the engineering for
interoperability principle, the cisco software will never send a DDN bound
datagram greater than 1006 bytes, but will accept larger datagrams.

Kirk Lougheed
cisco Systems
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Oct 88 10:06:10 -0400
From:      "Alan R. Hill" <ahill@CC5.BBN.COM>
To:        Rick Adams <rick@seismo.CSS.GOV>
Cc:        eagle_snax!geoff@DECVAX.DEC.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re: SLIP MTU "violation" - does anyone? does anyone care?
Rick,
	I'll probably regret this but I have to ask why you have the
impression that the IMP will not accept messages exceeding 1006 bytes?
The X.25 limit is 1024.  The 1822 limit is 8063 bits and the DDN
X.25 Standard service limit is 8056 bits or 1007 bytes.  Can you
shed some light on where the 1006 byte number originated?

Thanks,
Alan
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 07:19:53 GMT
From:      whwb@cgchb1.uucp (Hans W. Barz)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over DECnet ?

IBM has announced their MVS product for TCP/IP with the feature to run it over
SNA. IBM's product for VM has this ability already. Is their a product around
(or planned), which can do the same over DECnet? I know that I can run DECnet
and TCP/IP over the same Ethernet, but DECnet includes many different trans-
mission media.

Hans W. Barz    CIBA-GEIGY    CH-4001 Basle    mail:whwb@cgch.uucp

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 14:06:10 GMT
From:      ahill@CC5.BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP MTU "violation" - does anyone? does anyone care?

Rick,
	I'll probably regret this but I have to ask why you have the
impression that the IMP will not accept messages exceeding 1006 bytes?
The X.25 limit is 1024.  The 1822 limit is 8063 bits and the DDN
X.25 Standard service limit is 8056 bits or 1007 bytes.  Can you
shed some light on where the 1006 byte number originated?

Thanks,
Alan

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 16:13:34 GMT
From:      dorl@vms.macc.wisc.edu (Michael Dorl - MACC)
To:        comp.protocols.tcp-ip
Subject:   SLIP for Burroughs XE550 System V CENTIX 6.01 Wanted

We have a remote campus with a

  Burroughs XE550 

machine running a System V system called

  System V
  CENTIX 6.01

They are looking for anyone who has added slip to this system.

Michael Dorl (608) 262-0466
dorl@vms.macc.wisc.edu
dorl@wiscmacc.bitnet

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 17:01:30 GMT
From:      lougheed@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP MTU "violation" - does anyone? does anyone care?

Alan -

Regarding 1822 numerology:

8063/8 = 1007.875, so 1007 bytes is possible, but 1006 is the largest even
byte count.  Our experience on the DDN is that most systems use 1006 bytes
as the MTU.  Attempting to use a larger MTU has given us headaches,
especially with some Berkeley-derived systems.  Invoking the engineering for
interoperability principle, the cisco software will never send a DDN bound
datagram greater than 1006 bytes, but will accept larger datagrams.

Kirk Lougheed
cisco Systems

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 17:20:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   re: SLIP MTU "violation" - does anyone care?

>From: "Alan R. Hill" <ahill@CC5.BBN.COM>
>
>Rick,
>	I'll probably regret this but I have to ask why you have the
>impression that the IMP will not accept messages exceeding 1006 bytes?
>The X.25 limit is 1024.  The 1822 limit is 8063 bits and the DDN
>X.25 Standard service limit is 8056 bits or 1007 bytes.  Can you
>shed some light on where the 1006 byte number originated?
>
>Thanks,
>Alan

Alan,

I suspect that it dates back to old 1822 interfaces.  As you indicated,
for 1822, the limit is 1007 whole bytes.  But interfaces like the LH-DH/11
were 16-bit word oriented and therefore had a limit of 1006 bytes.
(IMP padding still occasionally nailed drivers not expecting more data
coming in than could be sent out)


+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@acc.arpa>		720 Santa Barbara Street		|
|	(805)963-9431		Santa Barbara, CA 93101			|
 +-----------------------------------------------------------------------+

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 17:25:53 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP using Telebit Trailblazers

Serial Line IP (recently discussed on this list in another context) runs
fairly well over Trailblazers.  There are some inefficiencies under some
conditions because minimum-length TCP packets fall into a length range that
the Trailblazer isn't optimized for.  Thus, TCP acks cost more bandwidth
than one might expect.

SLIP is described by RFC 1055, and commercial implementations are available
from FTP Software (for DOS PCs), cisco (terminal servers/routers), Encore
(terminal servers) and Spider Systems (???).  Public-domain source code for
4BSD Unix exists, too, and as far as I know, all the implementations
interoperate correctly.

Efforts are underway to develop a more general serial line protocol to
replace SLIP, but for now, it is a reasonable choice.

James VanBokkelen
FTP Software Inc.

PS:  Let me know if I missed any implementations, I think I know them all...

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 17:41:38 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP MTU "violation" - does anyone? does anyone care?

When I was running 4.2bsd (or maybe it was 4.1C?) on a vax connected to
an IMP via 1822 (circa 1983, when the code was written), "netstat -i"
showed an MTU of 1006 for the IMP interface.

I believe it is from the 1007 bytes rounded down to an even number
because of something that didn't work right with odd numbered MTUs.

As I said, it's an historical relic that there is no good reason for
perpetuating.

The "correct" MTU should really be something like 1024 data bytes + IP
headers + TCP headers.

Please keep in mind that SLIP was a hack. There was no real design to
it. It was a quick solution to an immediate problem. The framing scheme
was chosen to be compatible with 3Com's UNET (anyone still remember
that?). The MTU was chosen to avoid fragmenting when passing through
IMPS. Any other parameter you might find was chosen in a similar
manner. I.e. get it to work fast.

---rick

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 18:29:53 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip,comp.windows.news
Subject:   Re: Hello from INTEROP88

In article <Sep.29.16.40.16.1988.4903@ron.rutgers.edu> 
ron@ron.rutgers.edu (Ron Natalie) writes:
>I love a trade show that I can walk into almost any booth and
>get logged in at reasonable speed to my home machine.

	I thought that the "Show and Tel-Net" [ha ha] was very
effective.  I spent a lot of time banging on terminal servers while I
was at the show.  

	In fact, I read your article while connected from a telnet
session on a PC on token ring in U-B's booth in Santa Clara into my
home system in Boston.  And it was fast.

	The show nets were registered with the NIC, the nameservers
worked, SNMP worked and a hell of a lot of stuff interoperated.  I
thought that InterOp was a very good demonstration of how seriously
many vendors are taking interoperability.  Value added is now added on
top of the (standard) protocols and not with different and proprietary
(for their own sake) protocols.  Wave of the future?  I saw a lot of
product differentiation, it just wasn't at the protocol level, thank
god.

	Had a lot of fun, too.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 18:46:54 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

In article <8809271246.AA01355@ulana.b.mitre.org.> 
ulana@ulana.b.mitre.ORG writes:
>
>
>     The Electronic Systems Division (ESD) of the U.S. Air Force 
>is pleased to announce the award of the Unified Local Area 
>Network Architecture (ULANA) contracts.  
 [...]
>
>     The ULANA program will provide standardized Local Area 
>Networking components based on the IEEE 802.3 standard and the 
>DoD suite of protocols (TCP/IP, Telnet, FTP, SMTP, UDP, ICMP) The 
>components available from the ULANA contract will minimize 
>"unique" LAN implementations within the Air Force and permit 
>interconnectivity between Air Force standard computer systems.  
>
 [...]
>
>     Other equipment provided under the ULANA contract include 
>terminal servers, bridges, DDN gateway, LAN encryption and 
>media attachment units.  The media supported by the ULANA 
>components include baseband (both 10base2 and 10base5), dual 
>cable broadband, single cable broadband, fiber, and twisted pair.  
>

	Why didn't you just send a couple of bright Air Force officers
out to InterOp last week with some spec sheets and some POs?  You
could have saved yourself a lot of money on consulting fees and you
could have actually seen the stuff work before you bought it.

	Works for me.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 18:48:25 GMT
From:      tim@hoptoad.uucp (Tim Maroney)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac
Subject:   Re: TCP-IP libraries for Macs and ATs

In article <1300@gazette.bcm.tmc.edu> sob@watson.bcm.tmc.edu (Stan Barber)
writes:
>Apple announced MacTCP this week at Interop 88. It is supposedly based
>on the NCSA kernel and not the UMich stuff (or something link that).

That makes four attributions of the source so far: UofM, Apple, NCSA, and
Ungermann-Bass.  My money is now riding on the last one.  But who knows?

>It is NOT an end-user package but for developers only. Stanford-IP has been
>modified to fit as has NCSA Telnet. UB has the first product out on it.

How nice.  In their usual TOPS-bashing, Apple didn't bother to make us aware
of it when I was there.  I always get a kick out of it when Apple talks about
their wonderful support of third-party developers.

>Kinetics has also release a similiar product called TCPport. TOPS has not
>released anything like this, period. 
>Do you know if TOPS will, Tim?

Probably not; the TOPS developer program is a joke.  I have two fine pieces of
software, InterBase and TOPS TCP/IP, which would be perfect for it, but no
one has ever licensed them because the marketing boys at TOPS don't think
beta testing or the developer program are worth a full-time employee.  Grumble
grr hiss boo.  But TOPS TCP/IP stabilized last year, and had the last known
bug removed in the spring; it ought to be available now.  Maybe you could get
it if you asked.

What was that I said earlier about not wanting to appear mean-spirited toward
my former employer?  Oh well....
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Now hear a plain fact: Swedenborg has not written one new truth: Now hear
  another: he has written all the old falshoods.
 And now hear the reason.  He conversed with Angels who are all religious, &
  conversed not with Devils who all hate religion, for he was incapable
  thro' his conceited notions."
    - Blake, "The Marriage of Heaven and Hell"

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 20:03:37 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   BOOTP Extensions

Hello. RFC-1048 "BOOTP Vendor Information Extensions" by Philip Prindeville
defined additional BOOTP fields and a format for vendor-specific extensions.
I would like to know if anyone out there (1) has implemented, or (2)
plans to implement, any of the extensions described in this RFC.  Thanks.

Bob Braden

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 20:12:24 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   interop 88 exhibitors please read . . . . . .


when the clean up was done, peter de vries came up short 2 BICC
trancievers. i *think* they dont have taps on them, since we still
have the vampires for them. if you happened to find one in your stuff,
please let me know so we can make arrangements to get them back to BICC,
who loaned them to the show.


thanx . . . . . 

stev knowles
ftp software . . . . 

stev@ftp.com
617-868-4878

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 88 20:46:46 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: uunet catch-22: help!

As well as I can determine, the problem results from bad routes
resulting in extraordinary round trip times. The uunet computer was up
and happy.

There are several people claiming that someone is turning on packet
filtering on some of the mail bridges and screwing up the SMTP
traffic.  I have no data for or against that argument, so we can treat
it as an ugly rumor. (But it certainly would explain things!)

If anyone has a spare 1822 board for a Protoen gateway that they would
like to lend us for a few months, it would make things easier... As it
is, we are forced to continue limping along with running BRL's gateway
software on a PDP-11/44 with an LH/DH-11.

In the long run, we are scheduled to be connected to NSFNet (SURANET)
late this year. As far as routing goes, based on some stories I've
heard, I'm not sure if that will be an improvement or not!

---rick

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 01:04:56 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   RPI SGMP package

Has anyone taken the time to make this stuff run on a VAX? As written, it is
loaded with big-endian machine-dependancies which cause it to lose badly when
run on a VAX (surprisingly enough, it does compile and link, with only minor
changes). Yes, I know - SNMP is the wave of the short-term future, but for now,
I have some gateways that only speak SGMP and I'd like to poke at them.

	Vince Fuller, Stanford Networking
-------

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 01:05:09 GMT
From:      krm@bcsaic.UUCP (Keith Michaels)
To:        comp.protocols.tcp-ip
Subject:   Shutting down sockets on Apollo/VAX - reply

Re: Hung sockets on Apollo and VAX.

The following program releases socket connections that are left over
after a network application crashes on a VAX running Wollongong TCP/IP.
You have to know the INET: device name assigned to it -- this can sometimes 
be determined by checking the owning PID in SHOW DEV/FULL INET:.
This also seems to clean up the Apollo side at the other end of the link,
but I don't know how to do the equivalent operation from the Apollo.

/* Release unused INET: devices under Wollongong TCP/IP for VAX/VMS */
/* K. Michaels, BCS 27-Sep-1988 */

#include <stdio.h>
#include <ssdef.h>
#include <iodef.h>
#include <descrip.h>
main(ac,av)
int ac;
char *av[];
{
	int i;
	unsigned short iosb[4], chan;
	char idev[16];
	$DESCRIPTOR(idev_dsc,idev);
	if(av[1] == NULL) do {
		printf("inet device name: ");
		if(gets(idev) == 0) exit(SS$_NORMAL);
		} while (strlen(idev) == 0);
	else
		strcpy(idev,av[1]);
	idev_dsc.dsc$w_length = strlen(idev);
	i= sys$assign(&idev_dsc,&chan,0,0);
	if((i & 1) == 0) exit(i);
	i = sys$qiow(0,chan,IO$_SETCHAR,iosb,0,0,&0,0,0,0,0,0);
	if((i & 1) == 0) exit(i);
	if((iosb[0] & 1) == 0) exit(iosb[0]);
	sys$dassgn(chan);
	exit(SS$_NORMAL);
}

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Oct 88 15:12:45 EDT
From:      ted@nadc.arpa (T. Calkins)
To:        tcp-ip-relay@sri-nic.arpa
Subject:   Satellite Comm Systems
 
   I'm not sure that this is appropriate for this group, but with
the plethora of communications expertise, why not ...
 
   What hardware/software systems are available that support data
communications via satellite using a DEC VAX running the DEC VMS
Operating System?
  
   Please mail replies directly to me (unless there is other 
interest), i.e.  ted@NADC.ARPA. 
 
   Thanks in advance,
                       Ted Calkins  ( ted@NADC.ARPA )
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Oct 88 16:44:54 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

In article <25188@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>	Why didn't you just send a couple of bright Air Force officers
>out to InterOp last week with some spec sheets and some POs?  You
>could have saved yourself a lot of money on consulting fees and you
>could have actually seen the stuff work before you bought it.

As they say:  "A penny saved kills your career in the Pentagon."
-- 
The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 19:16:33 GMT
From:      mmorse@NOTE.NSF.GOV (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Re: pop2 and PC-NFS Lifeline


> After months of work and chasing down mulitple bugs we have brought up
> PC-NFS v 3.0.  Unfortunately, after we installed Lifeline (the pop2 client)
> for a PC, we find that it is NOT a TSR and thus has limited (if any real)
> usefulness.  

   You don't say what kind of PC you run, but my experience was
completely different.  I just loaded the software and it ran.  I had
to make some modifications to the POP server to make it work with
MMDF, but it ran out of the box with sendmail.  The Mail user
interface is too big to run as a TSR, but that doesn't make
it much less useful.  The user interface is so good it beats anything
running on a time-sharing machine (like our poor overloaded VAX).  It
is very fast and easy to use.  It compares with the best PC programs,
which are head and shoulders above anything available on a tty
connected to a central host.

   If TSR is of critical importance (obviously it's not for me), you
might want to look into one of the "context switching" programs for
DOS such as Desqview or DoubleDOS.  They should allow you to keep
LifeLine in memory, assuming you have enough memory to load LifeLine
and other programs.


> Has anyone created a pop2 client for the PC that will coexist
> with PC-NFS and remain as a TSR so that mail delivery is always available
> and relatively transparent?

   The pop2 client probably wouldn't be that difficult.  The problem is to
make a reasonably useful user interface that could be memory resident
on a PC.  I've never seen one.  In order to save memory so you can run
it TSR, you must delete functions.  This means that you have two user
interfaces, one full-blown to run from the DOS prompt, and one
stripped-down to run TSR.  My experience with the stripped down ones is
that you start to use it and become frustrated each time you want to
use a feature only available in the full version.  The solution most
vendors implement is to provide a small TSR product that only informs
you of mail, and perhaps gives the subject lines.  You still have to
exit your DOS application and start up mail if you want to read and
reply to the mail.  I think you'll just have to wait for OS/2.  The DOS
640K barrier is just too big a restriction. 

> Also, just as a general comment is everyone having a difficult time getting
> SUN to support PC-NFS?

My feeling was that it was a good thing that the software was so good,
because I couldn't get any information out of SUN.  The support people
admitted that they had never actually seen the product (PC-NFS), much
less used it.  I was never able to get in touch with anyone who knew
any more about the program than I could glean from the documentation.
This was many months ago, so things may have improved drastically in
the meantime.  It's obvious that there are some people at SUN who are
very sharp PC programmers, but they keep them pretty well protected
from their users.

--Mike

Michael Morse                           Internet: mmorse@note.nsf.gov
National Science Foundation               BITNET: mmorse@NSF
                                       Telephone: (202) 357-7659

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 20:50:03 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Concurrent TCP/IP

Afternoon all...
		I had a person call me asking me about TCP/IP implementations
for a Concurrent CPU. Not being conversant with Concurrent(can you SAY that |*)
I was at a bit of a loss. Anyone out there more familiar with Concurrent and
whether they play ball with the rest of us??
		THanks in advance,
				  Chris VandenBerg
				  ACC
				  (chris@acc-sb-unix.arpa)
				  805-963-9431

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 22:06:03 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet to a tcp port other than 23


*And he is, of course, correct.  It was my error in not clearly 
*explaining the problem.  I meant telnet for *MS-DOS*, as 
*distributed with PC-NFS.  Now that that's clear, any other ideas.

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


both PC/TCP from FTP Software and ka9q from Phil Karn
allow this . . . . . . . 

stev knowles
ftp software 
617-868-4878
stev@ftp.co

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 22:08:11 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   WIN_3.2 and STC_046, installed together

Looking for clues on anything I need to do to get WIN/TCP 3.2 to coexist
peacefully with my STC_046, Software Tools Mailer under VMS 4.6.  Looks
as though there are some SYSUAF, DAEMON/ACP, Directory overlaps.  Who
has done it.  A phone number, .COM file, clues ... any would be welcome.
-- 
 suned1!efb@elroy.JPL.Nasa.Gov   sun!tsunami!suned1!efb   efbatey@NSWSES.ARPA
    Any statements / opinions made here are mine, alone, not those of the    
    United States, the DoD, the Navy, the Congress, the Judiciary, nor ...   

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 22:12:05 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP Extensions

It seems that quite a few people have implemented it or will be soon.  I can
think of atleast two vendors with RFC 1048 compliant clients, and I remember
hearing from a few others.  We (CMU) have a functional RFC 1048 BOOTP server
that we will be distributing very soon.  We are currently adding truly dynamic
IP address assignment similar in concept to what MACs use.

Drew

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 88 23:48:17 GMT
From:      martinea@crc.skl.dnd.ca (Mike Martineau)
To:        comp.protocols.tcp-ip
Subject:   KA9Q with Turbo C


I am trying to get the KA9Q software up and running.  I have ftp'd
the Turbo C source from uunet.uu.net.  I have the code compiled
but I am experiencing some funnies turning execution.  Has anyone
successfully compiled and executed the Turbo C version of the KA9Q
software?  If so,  could you send me mail and let me know if you
encountered any problems.

Thanks.

Michael Martineau
Software Kinetics
crc.skl.dnd.ca (192.5.204.1)
1-613-831-0888

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Oct 88 08:15:24 EDT
From:      ted@NADC.ARPA (T. Calkins)
To:        tcp-ip@sri-nic.arpa
Subject:   Satellite Comm Systems
 
   I'm not sure that this is appropriate for this group, but with
the plethora of communications expertise, why not ...
 
   What hardware/software systems are available that support data
communications via satellite using a DEC VAX running the DEC VMS
Operating System?
  
   Please mail replies directly to me (unless there is other 
interest), i.e.  ted@NADC.ARPA. 
 
   Thanks in advance,
                       Ted Calkins  ( ted@NADC.ARPA )

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      05 Oct 88 08:40:38 EDT
From:      MIKEC@CSP-A.Prime.COM
To:        tcp-ip@sri-nic.arpa
Subject:   BBN reports mentioned in RFC979
Does anybody out there know where I can get copies of BBN reports 5476, 5500,
5760, and 5900 mentioned in RFC979?  It would be best if they were available
on-line, but I will take whatever I can get.

While I'm at it, does anybody have IEN-140 available on-line?  I tried to get
it from the NIC, but it is not available.  Although they did offer to get me a
hard copy for a minimal amount of money, I'd really like to get and keep this
on-line.

Please respond directly to me.  Many thanks in advance.


Mike Curtis
Prime Computer, Inc.

Of course, all opinions are mine - I don't get any at home$G!

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 11:54:14 GMT
From:      snorthc@NSWC-G.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: pop2 and PC-NFS Lifeline

>    If TSR is of critical importance (obviously it's not for me), you
> might want to look into one of the "context switching" programs for
> DOS such as Desqview or DoubleDOS.  They should allow you to keep
> LifeLine in memory, assuming you have enough memory to load LifeLine
> and other programs.

I have tried to run Lifeline under Windows/386.  I keep getting a
socket0 error when the POP client tries to run.  The problem may be
insuffcient free memory.  There is enough memory to compose/read and
queue mail however.


>    The pop2 client probably wouldn't be that difficult.  The problem is to
> make a reasonably useful user interface that could be memory resident
> on a PC.  I've never seen one.  In order to save memory so you can run
> it TSR, you must delete functions.  This means that you have two user
> interfaces, one full-blown to run from the DOS prompt, and one
> stripped-down to run TSR.  My experience with the stripped down ones is
> that you start to use it and become frustrated each time you want to
> use a feature only available in the full version.  The solution most
> vendors implement is to provide a small TSR product that only informs
> you of mail, and perhaps gives the subject lines.  You still have to
> exit your DOS application and start up mail if you want to read and
> reply to the mail.  I think you'll just have to wait for OS/2.  The DOS
> 640K barrier is just too big a restriction. 

I tend to agree, but maybe we won't have to wait for OS/2.  Sidekick plus
is an example of a very large and functional memory resident program
that uses ~64k of the lower 640 as a "kernal" and can stuff the rest
into LIM 4.0 space.

>> Also, just as a general comment is everyone having a difficult time getting
>> SUN to support PC-NFS?

Sometimes it seems like SUN NFS is the only reasonable alternative to
total Novell domination of the networked PCs world.  Too bad they don't
take their role more seriously.  I don't have a problem with Novell, it
is their protocol stack I would like to avoid.

I also had the same experience as Michael Morse, I just loaded the
SUN NFS SW and it ran.  The best support is not having problems.
When I had problems with PC NFS 2.0 and called SUN, 
they sent a patch for one problem and deferred the second till the
release of 3.0.

I am still making no headway with the Lan Manager supplied with the
Micorsoft OS/2 SDK and the 3c505 driver.  You think SUN support is bad,
try 3Com!!!!!!  Hopefully, I will get the update Microsoft said they shipped
two weeks ago any day now.  Any rumors of an OS/2 NFS component?

Stephen Northcutt (snorthc@nswc-g.arpa   (such as it is))

Take what I say with a grain of salt.  I test and evaluate products
from the companies mentioned, and document the results.  Your mileage
may differ.  Your opinions (and my management's) almost certainly will...

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 12:40:38 GMT
From:      MIKEC@CSP-A.Prime.COM
To:        comp.protocols.tcp-ip
Subject:   BBN reports mentioned in RFC979

Does anybody out there know where I can get copies of BBN reports 5476, 5500,
5760, and 5900 mentioned in RFC979?  It would be best if they were available
on-line, but I will take whatever I can get.

While I'm at it, does anybody have IEN-140 available on-line?  I tried to get
it from the NIC, but it is not available.  Although they did offer to get me a
hard copy for a minimal amount of money, I'd really like to get and keep this
on-line.

Please respond directly to me.  Many thanks in advance.


Mike Curtis
Prime Computer, Inc.

Of course, all opinions are mine - I don't get any at home$G!

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 21:13:00 MST
From:      <donrlee@sandia-2.arpa>
To:        "tcp-ip-relay" <tcp-ip-relay@sri-nic.arpa>
Subject:   RE: TCP/IP references
Try reading the documentation that comes with the KA9Q package. It is
the only one I know that is simple to read.
------
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 14:38:56 GMT
From:      tom@OSCSUNA (Thomas Easterday)
To:        comp.protocols.tcp-ip
Subject:   1822 loaner


  We have a 1822 DH board for a Proteon p4200 that we are not using.
  (our IMP is inactive and being removed)  Call me or send mail for
  details on loan.

				   Tom Easterday
				   The Ohio State University
				   Instruction and Research Computer Center

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 14:43:22 GMT
From:      tom@OSCSUNA (Thomas Easterday)
To:        comp.protocols.tcp-ip
Subject:   1822DH



  Oops, in a rush I forgot my phone number, (614) 292-4843.  
  Email tom@suna.osc.edu.

							 Tom Easterday
							 The Ohio State University
							 Instruction and Research Computer Center

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 15:55:56 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

>Why didn't you just send a couple of bright Air Force officers
>out to InterOp last week with some spec sheets and some POs?  
 
>As they say:  "A penny saved kills your career in the Pentagon."

Kent England and Henry Spencer appear to be buyers, not vendors; 
they do not have to make a living trying to develop and sell goods 
and services to public or private agencies.  
    Vendors want a fair shot at DoD dollars.  When they don't get it
they complain to their Congressmen, and Congress complains to DoD.
DoD procurement officials have to justify their decisions.  The
justification must have been a bit weak a few years ago; thus the 
Competition In Contracting Act (CICA) of 1984.  
    I'm not associated with the ULANA effort, but I do write technical
performance specifications for military systems.  The work is time
consuming and expensive, but to paraphrase Churchill on democracy:
It is the worst possible procurement system, except for all the others
that have been tried.

Regards - Craig

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 18:15:36 GMT
From:      tep@helix.UUCP (Tom Perrine x404)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP references


   Date: 2 Oct 88 15:17:08 GMT
   From: hamachi!eneevax.umd.edu!vidya  (Vidya Rajagopalan)
   Organization: Elec. Eng. Dept., U of Maryland, College Park, MD 20742
   Sender: hamachi!sri-nic.arpa!tcp-ip-request


   Can anybody on this net suggest some references to TCP/IP ?
   I am looking for some reading material regarding the protocols
   and standards as well as implementational details. I am particularly
   interested in a good introductory reference.

   I am planning to write a term paper on the subject and would appreciate
   any suggestions.


I cannot say enough good things about "Internetworking with TCP/IP" by
Douglas Comer. Everything I had to pick up by 4 years of reading RFCs
and source code is clearly spelled out in this wonderful book. It is
published by Prentice Hall. If you can't find it locally, try San
Diego Technical Books (1-800-346-0071) which does *lots* of mail
order.

Tom Perrine
Logicon(Tactical and Training Systems Division)	San Diego CA (619) 455-1330
UUland:		uunet!nosc!hamachi!tots!tep
Internet:	hamachi!tots!tep@NOSC.MIL

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 18:48:58 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet questions.

In article <8810031020.AA02610@ucbvax.Berkeley.EDU> RACKLEY@MSSTATE.BITNET
 (Mike Rackley) writes:
> Does the suggestion that we assign IP addresses in a "subnetted fashion"
> imply that we should also assign a subnet mask of other than 255.255.0.0?

  The suggestion that you assign your IP addresses in a ``subnet-like''
fashion was probably made to make switching over to subnets in the future
easier.  It doesn't hurt you to assign your addresses in a subnet-like
fashion - say by building or other organizational or geographic
assignment - and it makes dividing the administration of your net (ala
BIND subdomains for instance) and monitoring your net easier.  We
assigned buildings unique third byte IP addresses at Lawrence Livermore
National Lab for just those reasons even though LLNL isn't subnetted.

  I'd take the suggestion if I were you.

Casey

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 19:16:10 GMT
From:      tmt@xpiinc.UUCP (Thomas M. Talpey)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP Extensions

The new Visual V640 X Display Station (XDS) supports the BOOTP rfc1048
extensions plus the CMU vendor structure. Currently, the fields parsed are
the gateway, netmask, and name servers, as only those are of interest to the
device. The parameters are supplemented or overridden by user-provided local
setup.

If you haven't heard of the machine, it is an X (version 11) server running
in a terminal, over Ethernet and SLIP. The code is completely in ROM and the
machine does BOOTP (and RARP) if the IP address is not configured into its
local setup. With the extensions provided by rfc1048, plus some help from
the BOOTP server in providing an address, it is possible with no configuration
to take the machine out of the box, plug it in, and come up running X. Most
RARP and BOOTP servers currently require pre-configuration of the Ethernet
addresses, however, and will not reply to an unknown device. Therefore an
administrator must do something first, but BOOTP with rfc1048 makes the hard
part painless.

By the way, this machine begins a new Ethernet manufacturer ID field for
those interested, Visual Technology has been assigned 00:00:22.

Tom Talpey
Xpi Inc.
tmt@xpiinc.uu.net

Info on V640 XDS:
Visual Technology
(508) 459-4903
(800) VISUAL-C

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 19:41:31 GMT
From:      DOUG@mars.arc.nasa.gov (DOUG)
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

In article <1988Oct4.164454.16174@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <25188@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>>	Why didn't you just send a couple of bright Air Force officers
>>out to InterOp last week with some spec sheets and some POs?  You
>>could have saved yourself a lot of money on consulting fees and you
>>could have actually seen the stuff work before you bought it.
>
>As they say:  "A penny saved kills your career in the Pentagon."
>-- 
Cheap shots are all good clean fun, right?  More than a couple of
bright AF officers and contractors and civilians have been working
ULANA for some 4 or 5 years.  I think the spec was redone 3 times.
The users are AF-wide, and getting that large a community to spec
something in an evolving technology area like LAN architectures
was a real pain.  Tossing it off as a 2-person 2-week effort only
shows your lack of background on the project and its scope.

I didn't work on that project but I read 2 of the spec revisions in
'84 and '86.

Doug Olson
Digital Equipment Corporation
ex-USAF Lieutenant!

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 21:25:29 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet questions.

If your campus is connected together by datalink bridges rather than
routers, you are not really subnetting.  You are just imposing a scheme
for assigning numbers.  Leave the hosts thinking they are using an unsubnetted
class B network (which is what they are doing).  You can still assign the
more significant byte to be the building number and the least significant
one to be the host number.  That way if you ever do get smart and get
routers, you will already be ready to subnet.  You will avoid having
to renumber everything.

-Ron

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 88 22:53:47 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

In article <25188@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>	Why didn't you just send a couple of bright Air Force officers
>out to InterOp last week with some spec sheets and some POs?  You
>could have saved yourself a lot of money on consulting fees and you
>could have actually seen the stuff work before you bought it.

One should be somewhat more realistic.  The number of vendors that you
can go to and say "I'd like to buy 5000 IP routers, 4000 TCP terminal
servers, and 1000 miles of assorted interconnecting cables over the
next 5 years, and by the way, I expect you to install, interconnect,
maintain, and train our personnel in their use..." is approximately 0.

Thus some large company like TRW, who has experience in handling such
large bids, replys, and THEY send people to Interop and realted shows
to pick out routers, terminal servers, cable, modems, and so on.
Trying to grow a huge network one or two pieces at a time can be a
bad idea.  (Trying to plan a huge network in one fell swoop can also
be a bad idea...)

William Westfield
cisco Engineering
-------

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 00:02:49 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   New domain charts available

I've updated the domain chart once again.  This time it is 12 pages
long and no longer fits on my wall.  So, I made a second version
that only shows the 2nd level domains.  The abbreviated version
is only 7 pages.  Also, ASCII text listings of the domain names used
are also available.  For printing the domain charts you will need
a Postscript printer.

While collecting data for the chart I came up with a few random
incomplete statistics (these are minimum values):
  domains:  1180
  Internet hosts: 56000
  MX-only entries: 3500

You can retrieve the files via anonymous FTP to host SRI-NIC.ARPA,
or by sending mail to SERVICE@SRI-NIC.ARPA and placing "send pathname"
in the Subject line.

The file pathnames are:
  Full postscript chart:   NETINFO:DOMAIN-CHART.PS
  Full ascii listing:      NETINFO:DOMAIN-CHART-LIST.TXT
  Abbreviated chart:       NETINFO:DOMAIN-CHART-ABBREV.PS
  Abbreviated listing:     NETINFO:DOMAIN-CHART-ABBREV-LIST.TXT
-------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 00:03:25 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract


Kent and Henry,

It would indeed be nice to accost the vendors, checkbook in hand.
Unfortunately, government, and military especially, procurement
just doesn't work that way.  First of all, you have to understand
that, between wars, and sometimes during them, the bean counters
are in charge.  The little guy behind four locked and guarded
Pentagon doors is not a little man staring at a big red button.
Rather, it is a little guy with green eyeshaes and a helluvalot
of large tomes telling you why you can't buy the button, much
less press it.  Unfortunately, whenever someone tries to beat
the system, often as not with the taxpayers best interests in mind,
a scandal somehow erupts and congress gives the little guy some more
rules to tell you how you can't do things.

Enough flame -- there are some very valid reasons as well.
Primary among these is standardization.  To this audience, the first
reason for standardization -- interoperability -- should be
second nature.  But, there is more.  Standardization for logistics
reasons is vital to the military.  I've had to keep equipment operating
in the Arctic, the Antarctic, Iwo Jima, Japan, and several places
in between -- a lot of which aren't covered by your corner repair
centers.  The Navy currently haves something over 35 radar repeaters
in their inventory and keeping them all in parts is driving the
logistics guys nuts.  The third reason for standardization is the
human reason -- keeping maintenance and operator training costs
within bounds.  A common man-machine interface across a large
installed base has very large (if subtle and usually unnoticed)
benefits (remember the cars with push-button controlled automatic
transmissions?).

By far the most effective means to gain this standardization is exactly
what the Air Force has done -- get an open, requirements contract
out on the street.  Then the whole Air Force, not just a couple bright
guys, is only a PO away from a solution that has virtually all
of the standardization benefits.  Remember Herman Wouk's line in
Caine Mutiny -- the system was invented by geniuses to be run by
idiots.  How many people in the Air Force really know what
they should be buying?  

Rex Buddenberg
USCG Headquarters

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 00:51:00 GMT
From:      rich@RICE.EDU (Richard Murphey)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP references

take it from another novice, the book you want is:

"Internetworking with TCP/IP: principles, protocols, and
architecture," by Douglas Comer, published by Prentice Hall in 1988.

The reasons I liked the book can be stated plainly:
1) It builds on concepts with a gentle approach, starting with
the lowest layers (ARP and IP) and builds through TCP
to the higher layers (Telnet and FTP).

2) The appendix is great! It is almost 100 pages and covers
most of what you need to start using sockets in your own programs.
See appendix 1, 4.3 BSD UNIX interface to the internet protocols,
which includes an example `whois' client you can write.

3) It also has a good index and bibliography. Overall the organization
of the book is what makes it so useful. Let's put it this way: Kernihan
and Richie is a great C language book, but not much of a reference.
This book is both an introduction and a reference.


The book is $36. list and well worth it.

Enjoy!
richard

Richard Murphey, Electrical & Computer Engineering Department
Rice University P.O.Box1892 Houston,TX 77251 713-527-8101 X3649
Internet:crm@rice.edu Bitnet:crm%rice Uunet:uunet!rice.edu!crm

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 06:02:55 GMT
From:      jantypas@ucrmath.UUCP (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   KA9Q sources?

Where can one get the latest versions of KA9Q?  I have an old version but
it had some munged files in it.  (Including the docs.)  I have no real need
for tcp at the moment as I'm only running at 2400 baud, but I'd like to
learn about it at least.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Oct 88 16:31:58 EDT
From:      tsuchiya@gateway.mitre.org
To:        tcp-ip@sri-nic.arpa, zwang@Cs.Ucl.AC.UK
Subject:   Re:  simulation in computer networks
What exactly are you after, research info about simulator, or simply
coming up with a simulation package for your own use.

We at MITRE are using an event-driven network simulator to simulate
a routing algorithm written in C.  The package is commercial, is called
OPNET, is available from a Wash. DC company called MIL 3, costs $25,000
for companies, but they will sell it to universities that want to use
it for research for $5000.  It runs on Unix, Sun or Apollo.
I have been very happy with it.

Columbia University has another similar simulator that runs on Unix/Sun.
I don't have any first-hand experience with it, but it is free and
you get the source, so it has certain advantages.  It is called NEST.
You can call Alexander Dupuy about it +1-212-280-8622.  Sorry I
don't have his internet address.  Maybe he will see this message.

_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 13:20:09 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP support for 3C505 card

PC-NFS (and hence the PC-NFS Programmer's Toolkit) supports the
3C505.
-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:garnold@sun.com               +------------------------------------------+

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 13:47:52 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Telnet to a tcp port other than 23

I've posted a bug on the failure of PC-NFS Telnet to use \nfs\services
to determine the port to be used. However there is a workaround for now.
Instead of invoking the TELNET frontend, you can run the EMTELNET
program directly, using the following syntax:

	emtelnet IPADDR -p PORT -h HOST -e EMUL -d NFSDRIVE

for example

	emtelnet 192.9.215.185 -p 23 -h cookie -e VT100 -d C

The IPADDR and HOST refer to the same system: the HOST name is
used only for display purposes. (The objective here is to keep
the name resolution code out of the potentially TSRable Telnet runtime.)
-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:garnold@sun.com               +------------------------------------------+

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 14:19:00 GMT
From:      schoff@BEAR-MOUNTAIN.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract



    One should be somewhat more realistic.  The number of vendors that you
    can go to and say "I'd like to buy 5000 IP routers, 4000 TCP terminal
    servers, and 1000 miles of assorted interconnecting cables over the
    next 5 years, and by the way, I expect you to install, interconnect,
    maintain, and train our personnel in their use..." is approximately 0.

    Thus some large company like TRW, who has experience in handling such
    large bids, replys, and THEY send people to Interop and realted shows
    to pick out routers, terminal servers, cable, modems, and so on.
    Trying to grow a huge network one or two pieces at a time can be a
    bad idea.  (Trying to plan a huge network in one fell swoop can also
    be a bad idea...)

And now for a philosphical question:  Is this the shape of things
to come?  Will future tcp/ip acquisitions (and possibly iso/osi
acquisitions when it becomes real vs when GOSIP specifies) be so
large and complex that only large companies will be able to bid?

Marty

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 14:26:10 GMT
From:      sadler@shorty.CS.WISC.EDU (Jon B. Sadler)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q sources?

There are 2 ways to get the KA9Q sources.  They are: Anonymous FTP to
louie.udel.edu.  Look under pub/ka9q for .arc archives.  The other 
method is anonymous UUCP to winfree.UUCP.  Grab README for a discription
of what files are available there.

Winfree can be found at: 719/495-2061.  Login: Uanon Password: notFTP
	300, 1200, 2400 baud supported.

BTW, in order for you to unbundle a .arc file on a UNIX machine, you
will need the ARC program that is available from the comp.sources.unix
archive.  Anonymous FTP - j.cc.purdue.edu  and Anonymous UUCP - uunet.

Hope this helps

Jonathan Sadler
University of Wisconsin - Madison
INTERNET:  sadler@cs.wisc.edu         SNAIL MAIL:  Jonathan Sadler
           sadler@csd4.milw.wisc.edu               2350 Comp Sci + Stat (CSL)
UUCP    :  ...!rutgers!uwvax!sadler                University of Wisconsin
           sadler@uwvax.UUCP                       Madison, WI 53706
           ...chinet!laidbak!sadler   BELL NET:    (608) 262-2389

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 15:19:08 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

I can appreciate that a lot of work went into the spec, and I have only
seen one piece of it (the TCP/IP specifications), but I get the feeling
that at least a little of that was done in somewhat of an informational
vacuum.  Otherwise, why would they have: 1) asked that non-TOPS-20 systems
support FTP's "page mode", 2) required Satnet Stream ID as an IP Option,
3) used the MilStandards even when they are obsolete (for FTP) or
contain known errors (TCP and IP), and 4) not require subnet support?

If the "Requirements for Internet Hosts" RFC had been done a year ago,
would the authors of ULANA have known about it?  Could they have used
it, if they had (perhaps because it wasn't MilStd)?  I hope that the next
generation of this spec can, and does...

James VanBokkelen
FTP Software Inc.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 15:27:16 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP support for 3C505 card



>	I think NCSA Telnet 2.2 supports that card, though I've had some
>	problems getting it to work on some of my machines.  The software
>	is free, so it doesn't cost you anything to try.  Version 2.1
>	works fine but doesn't support a wide variety of ethernet boards.
>
>				Mike Berger
>				Department of Statistics 
>				Science, Technology, and Society
>				University of Illinois 
>
>				berger@clio.las.uiuc.edu
>				{convex | pur-ee}!uiucuxc!clio!berger


Sorry, NCSA Telnet does NOT support the 3C505 board in version 2.2.
We have a user-contributed driver for the 3C505 which works with a 
modified version of NCSA Telnet 2.1 -- anyone care to update it to
version 2.2?  Bruce (the author), have you updated it yet?


Tim Krauskopf                timk@ncsa.uiuc.edu (ARPA)

National Center for Supercomputing Applications (NCSA) 
University of Illinois, Urbana-Champaign

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Oct 88 15:36:55 GMT-0:00
From:      Zheng Wang <zwang@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   simulation in computer networks
Can anyone over there suggest me some references on simulation 
in computer networks, especially those about simulation of wide
area networks with distributed routing algorithms.

Thanks in advance.

Zheng

E-mail address: zwang@uk.ac.ucl.cs
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 16:15:15 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

Marty, these 'large' acquisitions are 'IDQ' type of contracts, meaing
that a vendor supplies a shopping list from which the government may
more easily buy and get support.  The government does not guarentte
any purchase but does limit the total value of the contract.  Most
of these supplies have teamed with the common vendors.  If the favorite
vendor of some government person is not on the list, I assume that
he can still compete the purchase and buy it (maybe even sole source
it if he has the requirements).

The big problem that these contracts are supposed to solve is the
integration and support role.  I suspect that any vendor who would
like to be on the approved list will eventually be able to go to
TRW/EDS and get their product approved.

dennis

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 16:43:58 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  U.S. Air Force Award of the ULANA Contract

Marty,

I would assume acquiring a large GOSIP data network will be like
acquiring a large ISDN (voice) network or a large PBX. System
integrators, they're called, something like a cross between an
elephant and a skunk.

Dave

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 16:53:47 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

In article <12436099307.19.BILLW@MATHOM.CISCO.COM> 
BILLW@MATHOM.CISCO.COM (William Westfield) writes:
>In article <25188@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>>	Why didn't you just send a couple of bright Air Force officers
>>out to InterOp last week with some spec sheets and some POs?  You
>>could have saved yourself a lot of money on consulting fees and you
>>could have actually seen the stuff work before you bought it.
>
>One should be somewhat more realistic.  The number of vendors that you
>can go to and say "I'd like to buy 5000 IP routers, 4000 TCP terminal
>servers, and 1000 miles of assorted interconnecting cables over the
>next 5 years, and by the way, I expect you to install, interconnect,
>maintain, and train our personnel in their use..." is approximately 0.
>
>Thus some large company like TRW, who has experience in handling such
>large bids, replys, and THEY send people to Interop and realted shows
>to pick out routers, terminal servers, cable, modems, and so on.

	Yes, that's right and I understand that both TRW and EDS
specified cisco routers for ULANA.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 88 17:09:13 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: U.S. Air Force Award of the ULANA Contract

In article <705@tetra.NOSC.MIL> 
budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) writes:
>
>Kent and Henry,
>
>It would indeed be nice to accost the vendors, checkbook in hand.
>Unfortunately, government, and military especially, procurement
>just doesn't work that way.  First of all, you have to understand
>that, between wars, and sometimes during them, the bean counters
>are in charge.  The little guy behind four locked and guarded
>Pentagon doors is not a little man staring at a big red button.
>Rather, it is a little guy with green eyeshaes and a helluvalot
>of large tomes telling you why you can't buy the button, much
>less press it.  Unfortunately, whenever someone tries to beat
>the system, often as not with the taxpayers best interests in mind,
>a scandal somehow erupts and congress gives the little guy some more
>rules to tell you how you can't do things.
>

	I do understand government and military procurement.  From
1979 to 1986 I was in the engineering consulting business working for
consulting firms that had contracts with the Navy, primarily.  I
worked on ballistic missile guidance and shipboard navigation systems
accuracy analysis and toward the end, on military tactical data
communications systems, like JTIDS.  I understand the business from
the small business setaside end of the table.  You know, where the dogs
gather to pick up the crumbs from the mouths of the Big Guys.

	Those that run things are the procurement types.  It's a
frustrating business working on scraps from the setasides, and that's
one of the reasons I got out.  I don't mean to disparage you or anyone
else, I'm talking about my personal views.  I'm having more fun on the
Internet than I ever would have figuring out how close to the Russian
silo a D5 missile can get.  :-)

	I really only meant to point out how nice InterOp was for
someone who doesn't have the weight of the Pentagon behind him.  I
really don't imagine that the Air Force will ever be able to operate
like a small, competitive enterprise like GM or IBM.  I know the facts
of life and that most everyone involved does his best to see that
useful work gets done in spite of the system of doing business.  So,
for those of you still on the inside, good luck, have fun, and do a
good job; I meant no disparagement to anyone working for or inside the
government procurement system.  I was poking at the "complex" Eisenhower
talked about when he left the Presidency.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 02:48:34 GMT
From:      morgan@Jessica.stanford.edu (RL "Bob" Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP Extensions


Drew Perkins writes:

> It seems that quite a few people have implemented [BootP extensions]
> or will be soon.  I can think of at least two vendors with RFC 1048
> compliant clients, and I remember hearing from a few others.

Which vendors?

> We (CMU) have a functional RFC 1048 BOOTP server that we will be
> distributing very soon.  We are currently adding truly dynamic IP
> address assignment similar in concept to what MACs use.

Hmm.  I've been thinking a lot about dynamic address assignment
myself.  I'd be curious to hear how (or if) you handle

1) ARP caches in hosts and gateways, as BootP clients cycle through
dynamically assigned addresses;

2) redundancy (that is, can you have a backup dynamic address server?);

3) multiple subnet service (that is, is the server restricted to
providing service to clients on its own subnet?).

 - RL "Bob" Morgan
   Networking Systems
   Stanford

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 03:04:19 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  BBN reports mentioned in RFC979

I probably have one of the most extensive collections of IENs online,
but I don't have IEN140. No help here.

Dave

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 04:04:10 GMT
From:      ane@hal.UUCP (Aydin "Bif" Edguer)
To:        comp.protocols.tcp-ip
Subject:   trailer encapsulation

Environment:
	DEC VAX 11-750, DEUNA, UNIX 4.3 BSD 
	Network environment is a number of Sun workstations and
	VAXstations.  Some VMS machines with either DECnet or
	Wollogong TCP/IP.  Some terminal servers running LAT.
Question:
	What are the hazards of running trailers?
More specifically:
I understand that the use of trailers is negotiated between hosts
and if a host does not support trailers then my host will not use
trailer encapsulation.  This negotiation uses ARP messages.
Can this negotiation break other implementations of tcp/ip?
Can the encapsulation itself interfere (with non-involved hosts)?
Does the use of trailer encapsulation interfere with other ethernet
protocols (DECnet, etc)?

I am really curious because I have been told by the network manager that
I MUST shut off trailers.  I thought that trailer encapsulation produced
a BIG win in performance (for the machines involved).  Is this true?
Does anyone have actual statistics on the difference (if any)?

Pointers to papers, books, etc appreciated.

Aydin Edguer					ane@hal.cwru.edu or hal!ane

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Oct 88 13:44:29 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   what is dynamic IP address assignment

Hi:

    I discovered at a lunch last week that there are two defintions of
dynamic IP address assignment floating around:

    (1) assigning an IP address, once and for all, to a new machine
    that has never been on the net before;

	and

    (2) assigning transient IP addresses to guest hosts (for example,
    a portable PC that has been plugged into your local Ethernet for
    the day by a visitor).

I get the impression lots of people are thinking about (1) and not many
about (2).  Personally, I think (2) is the more interesting problem
because it makes IP much more available to travelers.  (One can imagine
plugging one's PC into a jack in your airplane seat but I digress...)

Craig
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 08:35:28 GMT
From:      bert@hpuamsa.UUCP (Bert_Van Barneveld)
To:        comp.protocols.tcp-ip
Subject:   SLIP over Telnet...


Not having SLIP or any knowledge about it, I would like to know the following:

Would it be possible to run SLIP trough a so called terminal server ?
Most terminal servers run Telnet (MI NTS 100, Bridge CS100, UB NIU 180,
Spider etc.)

To do SLIP trough over an incoming telnet connection, it would have to run over
an arbitrary pty. 

Bert van Barneveld.
HP The Netherlands.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Oct 88 13:07:44 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        "Chris C. Corke" <uxc!ksuvax1!cseg!ccc1@csd1.milw.wisc.edu>, tcp-ip@sri-nic.arpa
Subject:   Re: Search for TCP-UUCP
> I am looking for a UUCP program which will run under TCP-IP on internet,
> instead of via phone line.

Why do you need/want UUCP?  RCP exists for exactly this purpose.

Doug Nelson
Computer Laboratory
Michigan State University
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 09:32:31 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  U.S. Air Force Award of the ULANA Contract

A cross between and elephant and a skunk?  I guess that is appropriate,
a large nose to be proportional to the smell!

:-)
 dennis

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri 7 Oct 88 13:36:16-EDT
From:      RichDeJordy, x295 <RAD@VAX02.AMS.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Personal Computers and TCP/IP

I have been commissioned to investigate the connection of micros to our
hosts. Our hosts are on an ethernet running both DECnet and TCP/IP.  I have 
some experience with VMS Services for DOS and with TSSnet, but I want to know
what TCP/IP software would be out there for Macintoshes or PCs connected to
the ethernet through Ethernet cards?  (I do have some information about the
Macintosh, but none about the PC. - Any information about products, concerns,
or implementations would be a great help.)

Thanks,
Richard DeJordy
Systems Programmer
American Mathematical Society
Post Office Box 6248
Providence, RI 02104
(401) 272-9500

RAD@MATH.AMS.COM on the Internet
-------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Oct 88 14:00:48 EDT
From:      stev@vax.ftp.com
To:        tcp-ip@sri-nic.arpa
Subject:   Re: BOOTP Extensions
*Hmm.  I've been thinking a lot about dynamic address assignment
*myself.  I'd be curious to hear how (or if) you handle

*1) ARP caches in hosts and gateways, as BootP clients cycle through
*dynamically assigned addresses;

*2) redundancy (that is, can you have a backup dynamic address server?);

*3) multiple subnet service (that is, is the server restricted to
*providing service to clients on its own subnet?).

* - RL "Bob" Morgan
*   Networking Systems
*   Stanford

what about trying to resolve addresses inbound? (like the ftpserver built into
NCSA telnet) are you tying this into the domain server?

what happens if it runs out of addresses in its subnet?

i think that dynamic address assignment *the first time* is a good thing,
but i think the sever should remember it for the future and always give the
same answer to the same machine . . . . . . (and maybe spread it around to 
the domain servers and other ip address assigners?)

stev knowles
ftp software
stev@ftp.com
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Oct 1988 14:04:02 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>, tcp-ip@sri-nic.arpa
Subject:   Re: Subnet questions.
Mike Rackley asks:

>Does the suggestion that we assign IP addresses in a "subnetted fashion"
>imply that we should also assign a subnet mask of other than 255.255.0.0?

No, your subnet mask should be 255.255.0.0.  You're just facilitating a
future migration to real subnetting, if/when needed.

Doug Nelson
Computer Laboratory
Michigan State University
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 15:07
From:      lowe%nac.DEC@decwrl.dec.com (Henry Lowe, LKG 1-2/A19, DTN 226-7546)
To:        tcp-ip@sri-nic.arpa
Subject:   Further on Reliability



     In response to John A.  Shriver's  note  (28  Sept  88)
     mentioning  end-to-end reliability with the DECnet file
     transfer protocol, DAP, the existence  or  lack  of  an
     end-to-end  CRC  check  in file transfer protocols does
     not necessarily reflect the reliability of the hardware
     supporting the file transfer service.

     A point in fact, Digital's motivation for  including  a
     CRC  in  DAP was not to compensate for DMC11/DMA Unibus
     errors, but to cater for the  transfer  of  very  large
     files where the cumulative probabilities of an error on
     transferring  each  block  in  a  file  (e.g.  one   in
     10**(-10) per block transferred as guaranteed by the 16
     bit lower layer CRC) could be  unacceptably  high.   We
     used another 16 bit CRC (polynomial different from that
     used in the lower layer) which is applied end-to-end to
     the  whole  file  being  transferred.   These  two CRCs
     together give the equivalent of a  single  31  bit  CRC
     which seemed adequate for the transfer of large files.

     The decision to include the end-to-end CRC in  DAP  was
     taken   before  we  knew  about  the  DMC11/DMA  Unibus
     problem.  Indeed, it was in testing this end-to-end CRC
     that  we discovered the DMC11/DMA Unibus problem.  This
     extra CRC was not added to cope with the problem.

     John's  summary  recommending  the  use  of  end-to-end
     checksums is indeed sound advice, not only to deal with
     lack of trust in hardware and  software,  but  also  to
     deal with cumulative small transmission errors.
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Oct 88 18:15:16 PDT
From:      croft@csli.Stanford.EDU
To:        <mar@ATHENA.MIT.EDU>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: BOOTP Extensions
> From: <mar@ATHENA.MIT.EDU>
> 
> We are examining dynamic address assignment here at Project Athena
> too.  However, we are not happy with BootP and RARP because they
> require advance configuration of the servers.  We are designing a new
> protocol for complete on-the-fly generation of new addresses along...

BOOTP protocol itself doesnt require advance configuration of the
servers, it is simply that the original BOOTP server was written this
way.  As CMU mentioned, it is possible to write a BOOTP server that
supports allocation and management of dynamic IP addresses.  If you
have a distributed server environment, the SERVERS might have a
dynamic 'voting' style protocol that they use amongst themselves to
divide allocation decisions.  But this protocol could be separate
from the client-oriented BOOTP, which is kept simple to fit within
boot prom situations.


-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 13:07:41 GMT
From:      sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet questions.

In article <Oct.5.17.25.28.1988.245@ron.rutgers.edu> ron@ron.rutgers.edu (Ron Natalie) writes:
>If your campus is connected together by datalink bridges rather than
>routers, you are not really subnetting.  You are just imposing a scheme
>for assigning numbers.

Unless, of couse, within these buildings you have hosts which are attached
to multiple networks (such as a local NFS net or PC net). Then you'll want
to run with subnetworks (in fact, you almost have to).

>Leave the hosts thinking they are using an unsubnetted
>class B network (which is what they are doing).  You can still assign the
>more significant byte to be the building number and the least significant
>one to be the host number.  That way if you ever do get smart and get
>routers, you will already be ready to subnet.  You will avoid having
>to renumber everything.

We have a similar thing at the University of Pittsburgh. The problems start
when someone wants to run subnets which will allow all hosts on any net to
talk to each other. My personal experience echoes Ron's suggestion. If you
even think that you MIGHT someday want to subnet somewhere, plan for it now.
It really does make life easier in the future. 

Sean McLinden

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 17:05:50 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   BOOTP Extensions

We are examining dynamic address assignment here at Project Athena
too.  However, we are not happy with BootP and RARP because they
require advance configuration of the servers.  We are designing a new
protocol for complete on-the-fly generation of new addresses along
with assignment of netmask, broadcast address, and default gateway.
Once the network interface is properly configured, it is possible to
go through gateways to servers elsewhere for more information.

Hopefully we will have a draft RFC available very soon.
					-Mark Rosenstein
					Project Athena Systems Development

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 17:07:44 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Search for TCP-UUCP

> I am looking for a UUCP program which will run under TCP-IP on internet,
> instead of via phone line.

Why do you need/want UUCP?  RCP exists for exactly this purpose.

Doug Nelson
Computer Laboratory
Michigan State University

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 17:36:16 GMT
From:      RAD@VAX02.AMS.COM (RichDeJordy@SRI-NIC.ARPA, x295)
To:        comp.protocols.tcp-ip
Subject:   Personal Computers and TCP/IP


I have been commissioned to investigate the connection of micros to our
hosts. Our hosts are on an ethernet running both DECnet and TCP/IP.  I have 
some experience with VMS Services for DOS and with TSSnet, but I want to know
what TCP/IP software would be out there for Macintoshes or PCs connected to
the ethernet through Ethernet cards?  (I do have some information about the
Macintosh, but none about the PC. - Any information about products, concerns,
or implementations would be a great help.)

Thanks,
Richard DeJordy
Systems Programmer
American Mathematical Society
Post Office Box 6248
Providence, RI 02104
(401) 272-9500

RAD@MATH.AMS.COM on the Internet
-------

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 17:44:29 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   what is dynamic IP address assignment


Hi:

    I discovered at a lunch last week that there are two defintions of
dynamic IP address assignment floating around:

    (1) assigning an IP address, once and for all, to a new machine
    that has never been on the net before;

	and

    (2) assigning transient IP addresses to guest hosts (for example,
    a portable PC that has been plugged into your local Ethernet for
    the day by a visitor).

I get the impression lots of people are thinking about (1) and not many
about (2).  Personally, I think (2) is the more interesting problem
because it makes IP much more available to travelers.  (One can imagine
plugging one's PC into a jack in your airplane seat but I digress...)

Craig

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 18:04:02 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet questions.

Mike Rackley asks:

>Does the suggestion that we assign IP addresses in a "subnetted fashion"
>imply that we should also assign a subnet mask of other than 255.255.0.0?

No, your subnet mask should be 255.255.0.0.  You're just facilitating a
future migration to real subnetting, if/when needed.

Doug Nelson
Computer Laboratory
Michigan State University

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 21:05:09 GMT
From:      akhanna@bbn.com (Atul Khanna)
To:        comp.protocols.tcp-ip
Subject:   connection-oriented v/s connectionless

Anyone have references to articles that touch upon the issue of
connectionless v/s connection-oriented protocols?

Thanks.

--------------------------------------------------------------------------
Atul C Khanna (akhanna@bbn.com)
BBN Communications Corporation
150 CambridgePark Drive
Cambridge, MA 02140

UUCP: ..!{decvax, wjh12, harvard}!bbnccv!akhanna

--------------------------------------------------------------------------
Atul C Khanna (akhanna@bbn.com)
BBN Communications Corporation
150 CambridgePark Drive
Cambridge, MA 02140

UUCP: ..!{decvax, wjh12, harvard}!bbnccv!akhanna

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 21:14:02 GMT
From:      acy@faron.icd.abnet.COM (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Sun-Bridge Freeze

We are having a problem communicating to Sun 3/60 workstations running
Sun OS 3 via TCP/IP with bridge boxes and ascii terminals.  About once
every five minutes output from the Sun stops for a period of about
seven seconds.

We performed a test to try and isolate the problem (and assign blame)
using a network analyzer and a simple echo loop and this is what we
discovered happens during a `freeze':

	Sun sends packet 1
	Bridge acks packet 1, window = 46
	Sun sends packet 2
	Bridge acks packet 2, window = 45
	Sun sends packet 3
	<five second pause>
	Sun sends packet 4
	Bridge acks packet 3, window = 45

It seems to me that what is happening is that the Bridge box is
dropping packets every now and then.  What I don't understand is why
the Sun waits five or so seconds before sending the next packet?  The
window is still open.  Shouldn't the Sun immediately send the next
packet?  If it did so, the Bridge would see that is lost a packet and
everything could recover much quicker.  (Although Bridge should fix
their box.  The packet obviously was delivered to them.  We got it on
the network analyzer.)  Could this be a bug in Sun's silly window
avoidance code?  (Does Sun have silly window avoidance code?  We don't
have source code to check.)
--

+-----------------------------------------------------------------------------+
|Adnan Yaqub   ...[cvedc|cwjcc|decvax|masscomp|mrmarx|pyramid|uunet]!abvax!acy|
|Allen-Bradley Company 747 Alpha Dr. Highland Hts. OH 44143 USA (216) 646-4409|
+-----------------------------------------------------------------------------+

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 21:43:00 GMT
From:      lance@redbaron.UUCP (Lance Browne)
To:        comp.protocols.tcp-ip
Subject:   security & network mail headers


Does anyone participating in this discussion group know of any work
done using the SMTP header field "Encrypted", which shows up on pages
24 and 25 of RFC 822?

A little background, we are currently working on trying to send an
SMTP mail message with a CRC based on the entire message (mail header
and text).  Since mail headers can change, and usually do, does anyone
know how it would be possible to CRC an entire message and pass the
message through the internet and have the CRC remain valid?  Could this
be done without changing SMTP requirements to recalculate a new CRC
after each header line is added?  

It is possible to CRC just the text of a mail message and trust the
mail header to only contain network relevant information, but that is
not desirable.

Thanks for any help.

+---+  Id:	Lance Browne
|\ /|  Net:	lance@logicon.arpa
| ? |  XXX:
|/ \|  USPS:	4010 Sorrento Valley Blvd, San Diego, CA 92121
 +---+  Phone:	(619) 455-1330

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 21:44:00 GMT
From:      lance@redbaron.UUCP (Lance Browne)
To:        comp.protocols.tcp-ip
Subject:   SFTP

Do any venders supply Simple File Transport Protocol commercially?
By "commercially" I mean does anyone have/sell the product
so that it would be considered COTS by the government.

Thanks for any information.

+---+  Id:	Lance Browne
|\ /|  Net:	lance@logicon.arpa
| ? |  XXX:	
|/ \|  USPS:	4010 Sorrento Valley Blvd, San Diego, CA 92121
+---+  Phone:	(619) 455-1330

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 88 23:12:17 GMT
From:      pasteur!agate!saturn!eshop@ucbvax.Berkeley.EDU  (Jim Warner)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: trailer encapsulation
In article <300@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes:

>I understand that the use of trailers is negotiated between hosts
>and if a host does not support trailers then my host will not use...

Trailers are negotiated between your host and the first hop gateway.
If the gateway agrees to trailers and the destination host does not,
the gateway must be prepared to convert trailer packets to normal
IP encapsulation.  This happens in 4.3BSD hosts that function as
routers.

>This negotiation uses ARP messages.
Hosts that want to do trailer encapsulation send two ARP requests,
one of type IP and the other of type trailers.  If the next hop
destination answers only the first of these, trailer encapsulation
is not used.  If it answers both, the ARP cache entry is marked as
safe for trailers.  'ifconfig'ing -trailers will prevent your host
from ever sending a trailer packet.  Independent of how this flag
is set, a 4.3BSD host will always accept a trailer encapsulated
packet.

>Can this negotiation break other implementations of tcp/ip?

I've never seen this as a problem, but I could write a version of
third party proxy arp that would "break" non-trailer implimentations.

>Can the encapsulation itself interfere (with non-involved hosts)?

Your network manager might own an ether-snooper that doesn't involve
trailers.  He might feel that "foreign packets" that his ether-snooper
can't grok interfers with his ability to manage the network.

>Does the use of trailer encapsulation interfere with other ethernet
>protocols (DECnet, etc)?

No.  

>I am really curious because I have been told by the network manager that
>I MUST shut off trailers.  I thought that trailer encapsulation produced
>a BIG win in performance (for the machines involved).  Is this true?

This is a debated point.  It probably is a performance win for the VAX
architecture only.  I'm not sure that I'd call it a BIG win.  

>Does anyone have actual statistics on the difference (if any)?

I saw a paper on the subject from BBN.  What you cannot do is run an
FTP with and without trailers and compare the transfer rates.  The
main effect of trailer encapulation on a VAX is to reduce the amount
of time the CPU spends copying data.  This shows up as more time
available for other processes rather than higher transfer rates.

jim warner
u.c. santa cruz
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 01:15:16 GMT
From:      croft@CSLI.STANFORD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP Extensions

> From: <mar@ATHENA.MIT.EDU>
> 
> We are examining dynamic address assignment here at Project Athena
> too.  However, we are not happy with BootP and RARP because they
> require advance configuration of the servers.  We are designing a new
> protocol for complete on-the-fly generation of new addresses along...

BOOTP protocol itself doesnt require advance configuration of the
servers, it is simply that the original BOOTP server was written this
way.  As CMU mentioned, it is possible to write a BOOTP server that
supports allocation and management of dynamic IP addresses.  If you
have a distributed server environment, the SERVERS might have a
dynamic 'voting' style protocol that they use amongst themselves to
divide allocation decisions.  But this protocol could be separate
from the client-oriented BOOTP, which is kept simple to fit within
boot prom situations.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 02:38:05 GMT
From:      sgi!vjs%rhyolite.SGI.COM@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: BOOTP Extensions
In article <8810032003.AA00478@braden.isi.edu>, braden@VENERA.ISI.EDU writes:
> Hello. RFC-1048 "BOOTP Vendor Information Extensions" by Philip Prindeville
> defined additional BOOTP fields and a format for vendor-specific extensions.
> I would like to know if anyone out there (1) has implemented, or (2)
> plans to implement, any of the extensions described in this RFC.  Thanks.
> 
> Bob Braden

Release 3.1 for IRIS 4D's uses RFC 1048.  We implemented some complient
extensions.  The code was done by the division which developed the
recently announced, low cost IRIS.  It solves disk-full installation
problems, when a new machine needs to discover its hostname, not just
its IP number.  I suspect we have not yet registered our magic number.
I think we decided a good choice is one of the IP network numbers SGI
has registered.  I don't recall if we did any of the other extensions
the RFC suggests, but certainly none that did not help solve the
problem at hand.

None of this is official.  If you need details or an official word, let
us know.

Vernon Schryver
Silicon Graphics
vjs@sgi.com
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 02:43:16 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP Extensions

> *Excerpts from ext.in.tcp-ip: 7-Oct-88 Re: BOOTP Extensions RL "Bob"*
> *Morgan@labrea.s (901)*
> 1) ARP caches in hosts and gateways, as BootP clients cycle through
> dynamically assigned addresses;

The ARP caches are expected to timeout faster than the BOOTP server timesout
addresses.  Reasonable ARP implementations should do this, although many ARP
implementations out there are not that reasonable...


>  2) redundancy (that is, can you have a backup dynamic address server?);
Yes, we plan on having redundant servers.  There are a number of possible ways
to do this, and we plan on experimenting a bit to see which would be best.
Possibilites are:
1.  Uncoordinated servers each use a separate range of addresses.  If the
client doesn't use the address assigned by a particular server then it should
time out quickly.
2.  Statically assign or dynamically elect primary/secondary labels for
servers.  The secondary servers could watch to see if the primary dies using a
separate protocol or based on the seconds-since-boot field in the BOOTP
request.  When the primary assigns an address it must also update the
secondaries somehow.  This also brings up the issue of keeping track of dynamic
assignments across crashes.

> 3) multiple subnet service (that is, is the server restricted to
> providing service to clients on its own subnet?).
No the server can serve multiple subnets using the gateway field in the BOOTP
request in order to determine the source subnet.  This does limit you to one
dynamic subnet per cable though.

Drew

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 04:00:36 GMT
From:      jim@b-mrda.UUCP (Jim Sadler)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP libraries for Macs and ATs

/ b-mrda:comp.protocols.tcp-ip / tim@hoptoad.uucp (Tim Maroney) / 11:48 am  Oct  3, 1988 /
>In article <1300@gazette.bcm.tmc.edu> sob@watson.bcm.tmc.edu (Stan Barber)
>writes:
>>Apple announced MacTCP this week at Interop 88. It is supposedly based
>>on the NCSA kernel and not the UMich stuff (or something link that).
>
>That makes four attributions of the source so far: UofM, Apple, NCSA, and
>Ungermann-Bass.  My money is now riding on the last one.  But who knows?

As I understand it UB has only developed the telnet and ftp "applications"
Apple did the development of the driver.

>
>>It is NOT an end-user package but for developers only. Stanford-IP has been
>>modified to fit as has NCSA Telnet. UB has the first product out on it.
>
>How nice.  In their usual TOPS-bashing, Apple didn't bother to make us aware
>of it when I was there.  I always get a kick out of it when Apple talks about
>their wonderful support of third-party developers.

Apple has a bad habit of not informing the people/companies that it should.
Unless of course you know someone who works in the labs.

>
>>Kinetics has also release a similiar product called TCPport. TOPS has not
>>released anything like this, period. 
>>Do you know if TOPS will, Tim?
>
>Probably not; the TOPS developer program is a joke.  I have two fine pieces of
>software, InterBase and TOPS TCP/IP, which would be perfect for it, but no
>one has ever licensed them because the marketing boys at TOPS don't think
>beta testing or the developer program are worth a full-time employee.  Grumble
>grr hiss boo.  But TOPS TCP/IP stabilized last year, and had the last known
>bug removed in the spring; it ought to be available now.  Maybe you could get
>it if you asked.

I have beta tested TOPS since days of when it had a rose icon.  I have seen 
at least 4 people in the job as beta/developer coordinator.  Something is not
right.  As far as developer programs forget it.  I tried for months to get the 
interfaces to TOPS.  I finally ended up with some Aztec C examples that had 
inline assembly code.  I've been testing Tops Terminal for I don't know how
long.  It's a nice product, I wonder what it's status is ?

>
>What was that I said earlier about not wanting to appear mean-spirited toward
>my former employer?  Oh well....
>-- 
>Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
>----------

		jim sadler
		206-234-5422
		hpubvwa!b-mrda!jim
		P.O. Box 3707 MS 6R-24
		Seattle, Wa. USA 98124

	Any opinions expressed are mine and mine only and not that of my
	employer.  Also add in whatever else should be said at this point.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1988 17:13-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        <mar@athena.mit.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: BOOTP Extensions
	From <mar@ATHENA.MIT.EDU>:
	...We are designing a new protocol for complete on-the-fly generation
	of new addresses along with assignment of netmask, broadcast address,
	and default gateway. ...

In general, a single default gateway address is insufficient (assuming
there is more than one gateway on the subnet), because that single gateway
may fail, leaving the host unable to communicate off-subnet despite the
presence of other operational gateways.  The draft Host Requirements RFC
recommends that a host be configured with a *set* of default gateway
addresses.  The Host Requirements working group is also working on a
proposal for dynamic discovery of all operational gateways on a single
subnet, using multicast or broadcast where available.

Regarding on-the-fly generation of host addresses, doesn't the small
size of IP addresses present a fundamental problem?  Many networks
are class C or subnetted class B, with only 8 bits of host number.
If the host population is large or very volatile, you will have to
recycle addresses, but in the absence of human administrative control,
there is no way to determine reliably that an address is free for
reassignment.  You can't just poll an address to see if it is in
use, because the user of the address may be temporarily unreachable
from the system that assigns the addresses.  Are you planning to
handle address recycling?

Steve
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 13:26:49 GMT
From:      sun.soe!sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu  (Russ Nelson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Personal Computers and TCP/IP
In article <8810081206.AA08560@ucbvax.Berkeley.EDU> RAD@VAX02.AMS.COM (RichDeJordy@SRI-NIC.ARPA, x295) writes:

   I have been commissioned to investigate the connection of micros to
   our hosts.  ... I want to know what TCP/IP software would be out there
   for Macintoshes or PCs connected to the ethernet through Ethernet
   cards?

If you haven't yet, you should see netinfo:vendors-guide.doc on sri-nic.arpa.

If you've seen that document, then I have nothing to add to it, other than
to recommend Phil Karn's package if you're interested in hacking, or NCSA's
package if you have non-tcp/ip-aware users.  Karn's package may require some
negotiation because it is freely copyable only by non-commercial and non-
governmental entities.  NCSA's package is in the public domain.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
To surrender is to remain in the hands of barbarians for the rest of my life.
To fight is to leave my bones exposed in the desert waste.
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1988 17:37-EDT
From:      CERF@A.ISI.EDU
To:        RAD@MATH.AMS.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Personal Computers and TCP/IP
Apple Computer Corp has just announced MacTCP - it is a product for
developers who want to build applications operating above TCP.

The person at Apple to contact is Gursharan Sidhu or Jim Mathis, both
in the Cupertino headquarters offices, I believe.

A developer would pay $2500 for the MacTCP package and, if products
are marketed based on the MacTCP, Apple requires another $2500 license
fee. End user packages would presumably be much less expensive.

Stanford has developed some applications operating above MacTCP,
but these have not been commercially productized, so far as I know.
There are other vendors who exhibited products  at the Interop 88
show in Santa Clara, sponsored by Dan Lynch's ACE organization.

Vint Cerf
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1988 18:01-EDT
From:      CERF@A.ISI.EDU
To:        mckenzie@LABS-N.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  ST in Gateways
For Dave Cheriton and Alex McKenzie:

1. ST was an experiment in real-time communication on the Internet.
   The ST protocol, which operates at the level of IP (adjacent to it),
   had special features to support multicasting for voice conferencing,
   for instance.

2. It seems to me that the more useful debate would be whether ST or
   Muilticast or perhaps something along the VMTP lines is the more
   suitable for carrying out the kinds of explorations that Claudio
   wants to pursue. ST has a lot of features that emerged from
   pracitcal voice conferencing experiments which included long-delay
   satellite channels as well as the terrestrial Internet and, if
   memory serves, at least one packet radio network.

3. Yes, Alex, you can claim to be one of the IP and TCP developers -
   it was and continues to be an effort engaging the ideas and skills
   of many people.

Vint
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 16:42:51 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  what is dynamic IP address assignment

Craig,

Yummy, you stroked one of my favorite personal chords. Unpeeling another
layer, the issue is whether you take your personal address with you or
borrow one at your destination. The former approach is more fun, even if
it does seem to require a flat address space. However, if you treat
roaming hosts as relatively rare, you can map "tunnels" onto the routing
fabric of your net through suitable modification of the routing tables
and update message formats. Some nets, including the Phas-I NSFNET
Backbone and several fuzzball nets scattered about the netscape in fact
include this feature. That's how my personal fuzzball at home pretends
it has addresses on three nets, including ARPANET (using transparent-
host addressing), but is some hops behind the gateway to those nets.

It's all done with mask-and-match tables and logical-host addressing,
folks. A ubiquitous roaming feature like this could be incorporated
into the Internet architecture by suitable modification of several
hundred gatewasy. Only.

Dave

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 21:37:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Personal Computers and TCP/IP

Apple Computer Corp has just announced MacTCP - it is a product for
developers who want to build applications operating above TCP.

The person at Apple to contact is Gursharan Sidhu or Jim Mathis, both
in the Cupertino headquarters offices, I believe.

A developer would pay $2500 for the MacTCP package and, if products
are marketed based on the MacTCP, Apple requires another $2500 license
fee. End user packages would presumably be much less expensive.

Stanford has developed some applications operating above MacTCP,
but these have not been commercially productized, so far as I know.
There are other vendors who exhibited products  at the Interop 88
show in Santa Clara, sponsored by Dan Lynch's ACE organization.

Vint Cerf

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 22:01:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ST in Gateways

For Dave Cheriton and Alex McKenzie:

1. ST was an experiment in real-time communication on the Internet.
   The ST protocol, which operates at the level of IP (adjacent to it),
   had special features to support multicasting for voice conferencing,
   for instance.

2. It seems to me that the more useful debate would be whether ST or
   Muilticast or perhaps something along the VMTP lines is the more
   suitable for carrying out the kinds of explorations that Claudio
   wants to pursue. ST has a lot of features that emerged from
   pracitcal voice conferencing experiments which included long-delay
   satellite channels as well as the terrestrial Internet and, if
   memory serves, at least one packet radio network.

3. Yes, Alex, you can claim to be one of the IP and TCP developers -
   it was and continues to be an effort engaging the ideas and skills
   of many people.

Vint

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 88 22:36:33 GMT
From:      zsu@ISTC.SRI.COM (Zaw-Sing Su)
To:        comp.protocols.tcp-ip
Subject:   Re: what is dynamic IP address assignment


Craig,

The two cases you mentioned imply different semantics for the "IP address".
In case (a), the IP address is in reality a name, while it is an honest,
goodness address for case (b).  [re: Shoch's classic paper on naming and
addressing]

I second Dave that your case (b) is far more interesting.  Our Reconstitution
(Routing) Protocol (RP) Program supported by RADC and SAC a few years
back tackled a solution to your case (b) right on.  It was a pioneering
effort in that direction.  Prototypes were built and capability of
our solution tackling your case (b) was successfully demonstrated in
a series of SAC C3 Experiments.  It is backward compatible across EGP
to the IP Internet.  Our basic approach was to separate the double
semantics (as a name as well as an address) IP address carries.  To
facilitate address changes, we used gateway-centric addressing (in
IP format) instead of network-centric as IP stands.  (Gateway-centric
addressing is a predecessor of Paul Tsuchiya's Landmark Routing, if
you are familiar with Paul's work.)

My assessment of that effort (could be very biased since I authored
RP protocol) is that it was (and still is, in my opinion) a promising
direction to pursue.  In spite of our success, further effort is necessary
to evaluate what have been achieved and how to bring it further into
a practical system.  Further research is clearly necessary for RP to
operate in a ubiquitous mobile environment which Dave alludes to.

Zaw-Sing

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 88 00:13:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP Extensions


	From <mar@ATHENA.MIT.EDU>:
	...We are designing a new protocol for complete on-the-fly generation
	of new addresses along with assignment of netmask, broadcast address,
	and default gateway. ...

In general, a single default gateway address is insufficient (assuming
there is more than one gateway on the subnet), because that single gateway
may fail, leaving the host unable to communicate off-subnet despite the
presence of other operational gateways.  The draft Host Requirements RFC
recommends that a host be configured with a *set* of default gateway
addresses.  The Host Requirements working group is also working on a
proposal for dynamic discovery of all operational gateways on a single
subnet, using multicast or broadcast where available.

Regarding on-the-fly generation of host addresses, doesn't the small
size of IP addresses present a fundamental problem?  Many networks
are class C or subnetted class B, with only 8 bits of host number.
If the host population is large or very volatile, you will have to
recycle addresses, but in the absence of human administrative control,
there is no way to determine reliably that an address is free for
reassignment.  You can't just poll an address to see if it is in
use, because the user of the address may be temporarily unreachable
from the system that assigns the addresses.  Are you planning to
handle address recycling?

Steve

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 88 03:27:38 GMT
From:      idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL])
To:        comp.protocols.tcp-ip,comp.dcom.modems,comp.dcom.lans
Subject:   Re: Wanted: SLIP oer 9600-baud modems -- Ultrix 2.x/4.3bsd

In article <166@tunscs.UUCP> jost@tunscs.UUCP (Allan Jost) writes:
> Has anyone successfully installed and used SLIP under Ultrix?

I managed to get SLIP working using direct-connected Trailblazer modems
at 19200 bps between two VaxStation 2000 Ultrix 2.0 systems using some
4.3bsd SLIP source from the net, slightly modified to compile and fit
into our Ultrix binary distribution.  Interactive response (via rlogin
over the SLIP line) was abysmal.  Bulk data transfer (via rcp) was not
bad for large files.  I was going to test interactive response with
data compression mode off, to see if that helped, but I haven't done
that yet.  Ultrix 2.4 seems to have a much nicer dial-up SLIP
capability via an /etc/sliphosts file and login accounts that run
/etc/slattach.  Haven't tried that yet.
-- 
        -IAN!  (Ian! D. Allen)      University of Waterloo

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 1988 14:19-EDT
From:      CERF@A.ISI.EDU
To:        zsu@TSCA.ISTC.SRI.COM
Cc:        craig@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA
Subject:   Re: what is dynamic IP address assignment
Zaw-Sing,

Did the RP work ever appear in RFC form? Are there readily-available
papers?

Vint
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 88 18:19:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: what is dynamic IP address assignment

Zaw-Sing,

Did the RP work ever appear in RFC form? Are there readily-available
papers?

Vint

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 88 19:54:13 GMT
From:      zsu@TSCA.ISTC.SRI.COM (Zaw-Sing Su)
To:        comp.protocols.tcp-ip
Subject:   Re: what is dynamic IP address assignment


Vint,

I don't know how I missed mentioning, in my last message, that DARPA
has co-sponsored this program.  Sorry!

Unfortunately, we did not publish an RFC on this subject.  There were two
papers published in conferences, one in 7th ICCC, and the other INFOCOM 85.
They were both titled "Internet Accommodation of Network Dynamics: ..."
A more complete documentation of this effort is our final report to
RADC/DARPA.  I might still have a couple of extra copies.

Zaw-Sing

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 88 00:23:38 GMT
From:      adt@hpausla.HP.COM (Andrew Tune)
To:        comp.protocols.tcp-ip
Subject:   SLIP on SunOS 4.0

Anyone have SLIP running on SunOS 4.0?  Please post replies.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Oct 88 09:23:39 PDT
From:      hamachi!tots!tep@nosc.mil (Tom Perrine x404)
To:        hamachi!logicon.ARPA!redbaron!lance@nosc.mil
Cc:        tcp-ip@sri-nic.arpa
Subject:   SFTP
Hmmm. Do you want SFTP (RFC913) or TFTP (Trivial File Transport
Protocol,RFC783)?

TFTP is widely available from commercial vendors, mostly because it is
also used to boot diskless workstations (Sun,Apollo,etc.) DEC supports
it in their NFS product, because it allows them to be boot servers for
diskless Suns....

SFTP is still listed by the NIC as an experimental protocol, so I
doubt you'll find any commercial vendors.

Good Luck...

Tom Perrine
Logicon(Tactical and Training Systems Division)	San Diego CA (619) 455-1330
UUland:		uunet!nosc!hamachi!tots!tep
Internet:	hamachi!tots!tep@NOSC.MIL
"Have you qualified for Raw Bits Cereal? Oat Hulls and Wheat Chaff.
*The*  Breakfast of Bare-Metal programmers!"
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 1988 10:42-EDT
From:      CERF@A.ISI.EDU
To:        zsu@TSCA.ISTC.SRI.COM
Cc:        craig@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA
Subject:   Re: what is dynamic IP address assignment
Zaw-Sing,

I would verymuch like a copy of the final report or reference to
comparable DTIC or NTIS versions:

send to:

Vint Cerf
Corp. for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091

thanks,

Vint
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Oct 88 14:32:25 PDT
From:      postel@venera.isi.edu
To:        jos@idca.tds.philips.nl, tcp-ip@sri-nic.arpa
Cc:        jkrey@venera.isi.edu, postel@venera.isi.edu
Subject:   RFC822 Encryption Types

Jos Vos:

No encryption types have been registered. 

When there are registered encryption types they will be listed in 
"Assigned Numbers". 

Do you want to be the first?

However, please see RFC-1040 on Privacy for Electronic Mail.

--jon.
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Oct 88 15:56:05 -0400 (EDT)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: what is dynamic IP address assignment
> *Excerpts from ext.in.tcp-ip: 7-Oct-88 what is dynamic IP address .. Craig*
> *Partridge@NNSC.NSF (699)*
>     I discovered at a lunch last week that there are two defintions of
> dynamic IP address assignment floating around:
>     (1) assigning an IP address, once and for all, to a new machine
>     that has never been on the net before;
>       and
>     (2) assigning transient IP addresses to guest hosts (for example,
>     a portable PC that has been plugged into your local Ethernet for
>     the day by a visitor).
I'm thinking about both.  However, I'm not quite sure you need to make much of
a distinction.  How should the server you tell the difference?  Why should it?
Maybe the two are not really distinct but are two extremes of a larger problem.

Drew
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 1988 21:17-EDT
From:      CERF@A.ISI.EDU
To:        hamachi!tots!tep@TROUT.NOSC.MIL
Cc:        hamachi!logicon.ARPA!redbaron!lance@TROUT.NOSC.MIL, tcp-ip@SRI-NIC.ARPA
Subject:   Re: SFTP
MCI implemented and used SFTP in MCI Mail but did not make the
SFTP implementations separately available as products.

Vint Cerf
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 88 17:36:56 GMT
From:      tencati%jplgp.span@VLSI.JPL.NASA.GOV
To:        comp.protocols.tcp-ip
Subject:   RE: TCP/IP over DECnet ?

Hans,

Contact Ken Adelman (KEN@WARBUCKS.AI.SRI.COM).  He has written a TCP/IP
over DECnet program.  This works in conjunction with SRI's Multinet TCP/IP
I believe..

Ron Tencati
Jet Propulsion Laboratory
Pasadena, Ca
USA

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 88 20:01:05 GMT
From:      rogerk@mips.COM (Roger B.A. Klorese)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   SLIPDISC Streams Module?

Does anyone have a SysVR3 SLIPDISC implementation under a streams tty driver?
I would like to prepare a customer for our forthcoming merged OS, and also
make this available for current SysV customers.
-- 
Roger B.A. Klorese                               MIPS Computer Systems, Inc.
{ames,decwrl,prls,pyramid}!mips!rogerk	                  928 E. Arques Ave.
rogerk@mips.COM (rogerk%mips.COM@ames.arc.nasa.gov)     Sunnyvale, CA  94086
I don't think we're in toto anymore, Kansas.                 +1 408 991-7802

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 88 23:36:56 GMT
From:      stevens@hsi.UUCP (Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   NetBIOS over TCP/UDP

Is anyone aware of any implementations of NetBIOS over TCP/UDP,
as specified in RFCs 1001 and 1002 ??  (I posted this to the
comp.protocols.ibm newsgroup last week and got zero response.)

Also, if such a beast exists, does it have a *reasonable*
user interface, as opposed to the PC NetBIOS interface,
where everything is done through a single function call with
a single argument (a pointer to an Ncb) ?

	Richard Stevens
	Health Systems International, New Haven, CT
	   stevens@hsi.uu.net
           ... { uunet | yale } ! hsi ! stevens

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 00:01:40 GMT
From:      reidar@cucard.UUCP (reidar)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   FTP failure

References:
Sender: 
Reply-To: reidar@cucard.UUCP (reidar)
Followup-To: 
Distribution: 
Organization: Columbia University College of Physicians and Surgeons
Keywords: FTP file transfer 

I am only recently connected to the internet and have a possibly naive
problem.  I am running 4.3bsd on a /750. I am trying to get the Van
Jacobson tcp changes from ucbarpa. Ftp will only complete file transfers
of small (<10k bytes) files.  Am I the victim of an overloaded internet,
a well-known ftp bug, a set up mistake, ...? I have tried more than 30 times
to get these files, i tried at various bizarre times (e.g. 4 AM EST), it always
times out after transmitting a partial file or  nothing.
   I have had a similar experience trying to ftp the tex files from 
labrea.stanford. These are each 512000 bytes long and I have variable success
ftping them.  I have gotten 20 of the 43 files after many tries.
	I would appreciate guidance.

-- 
Reidar Bornholdt
..!{cmcl2,usenix}!cucard!reidar

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 00:53:48 GMT
From:      sean@arizona.edu (Sean O'Malley)
To:        comp.protocols.tcp-ip
Subject:   Streams Source Code?

The Xkernel research group at the University of Ariziona
is looking for source code of protocol implementations 
using UNIX system V streams. TCP/IP would be nice but any
protocol source would be nice. We need the code for 
research purposes only. We would prefer public domain 
code. It would be nice if the code worked but robustness
is not important. 

Send any reply's to: sean@arizona.edu (CSNET)

Thanks 
Sean O'Malley
 

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 08:44:58 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        ddp+@andrew.cmu.edu
Cc:        deering@pescadero.stanford.edu, tcp-ip@sri-nic.ARPA
Subject:   dynamic IP assignment

> You can't just poll an address to see if it is in
> use, because the user of the address may be temporarily unreachable
> from the system that assigns the addresses.  Are you planning to
> handle address recycling?

Drew:

    This comment from Steve Deering points up why I think short-term
(transient) dynamic assignment vs. permanent assignment are very
different problems.

    Consider that if one has a server that hands out transient addresses one
can set some strict rules about when those addresses will be assumed to be
no longer in use (for example, if an ARP request for IP address ever fails)
while if you are handing out semi-permanent addresses (i.e. for a workstation
likely to be around for months or years) a more rigorous test for the
``liveness'' of an IP address is required.

Craig
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 02:05:16 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over DECnet ?

Sure call up The Wollongong Group.  They call it dbridge.  We used
it for a while, but then we just got our routers to do both TCP/IP
and DECNET.

-Ron

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 02:06:38 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP MTU "violation" - does anyone? does anyone care?

Many PDP-11 IMP interfaces can transfer odd number of bytes well so
the outbound MTU was frequently set to 1006 to avoid this problem.
Inbound didn't matter because the imp always spit out a few extra bytes
on the end of the message.

-Ron

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 02:23:21 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over Telnet...

>Would it be possible to run SLIP trough a so called terminal server ?

A more reasonable use of a terminal server would be for it to support
SLIP directly.  Cisco does that.  It's fairly easy, so I would think
others would as well.  It seems a bit odd to take a SLIP connection,
which after all is IP packets, encapulate it in TCP/IP again, and then
send it through a Unix pty on its way to a final SLIP interpreter.
Yuck.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 09:38:50 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Cc:        ddp+@andrew.cmu.edu
Subject:   dynamic IP assignment (typo)

> Consider that if one has a server that hands out transient addresses one
> can set some strict rules about when those addresses will be assumed to be
> no longer in use (for example, if an ARP request for IP address ever fails)

should be

 Consider that if one has a server that hands out transient addresses one
 can set some *simple* rules about when those addresses will be assumed to be
 no longer in use (for example, if an ARP request for IP address ever fails)

Craig
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 03:51:13 GMT
From:      morgan@Jessica.stanford.edu (RL "Bob" Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: what is dynamic IP address assignment


Paraphrasing Craig Partridge, the two types of dynamic IP address
assignment are:

1) assigning a (more or less permanent) address to a new host on the net;

2) assigning a temporary address to a host that happens to need one.

Craig thinks that most people are thinking about 1) rather than 2).  I
think not.  Far from 2) being a convenience when a visiting dignitary
comes to town with their Ethernet-adapter-equipped portable PC, I
think it should be the way most machines on the net get their
addresses.  I invite everyone who thinks dynamic IP address assignment
is a simply a cute idea to accompany me the next time I have to assist
a former secretary or part-time graduate student who has been put in
charge of a departmental network here, and help me explain IP
addresses, BOOTP tables, and default gateways.  This sort of stuff is
tricky yet tedious, so unskilled people screw it up, and skilled
people are too busy doing something else.  If we can't design these
nets so that the standard end-user station can start using the net
with ABSOLUTELY NO CONFIGURATION, then we have failed.

What distinguishes a station as a candidate for dynamic addressing is
that it supports only client-side software.  I think "client-only"
stations may be different enough from "hosts" (as well as far more
numerous) that it's worth thinking about how their "requirements"
differ (ala the ever-forthcoming RFC).  Yes?  No?

 - RL "Bob" Morgan
   Networking Systems
   Stanford

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 12:28:21 -0400 (EDT)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        Craig Partridge <craig@nnsc.nsf.net>
Cc:        deering@pescadero.stanford.edu, tcp-ip@sri-nic.arpa
Subject:   Re: dynamic IP assignment
> *Excerpts from mail: 11-Oct-88 dynamic IP assignment Craig*
> *Partridge@NNSC.NSF (807)*
> > You can't just poll an address to see if it is in
> > use, because the user of the address may be temporarily unreachable
> > from the system that assigns the addresses.  Are you planning to
> > handle address recycling?
> Drew:
>     This comment from Steve Deering points up why I think short-term
> (transient) dynamic assignment vs. permanent assignment are very
> different problems.

I think this issue only comes up when you have a small number of addresses
available but you have a high "churn" (Millspeak).  When you have a large
number of addresses available, you can be very conservative with recycling
them.  I.e. if you have a sufficient number of addresses available, you may be
able to wait 1 week before you have to recycle any particular address.

The question is, how conservative can we be in typical environments?  In your
first example, we can be very conservative, in the second maybe not.  One
answer is to make the let the network manager make the decision.  The number of
addresses that you allocate to the server as well as the minimum recycle time
can be configurable parameters for the server.

It may also be possible for the server to figure this out for itself using some
heuristics.  The server should probably keep records on when addresses were
allocated, when they were last in use, rate of address allocation, etc.  For
any particular address, the server may be able to figure out whether it is
transient or permanent.  If an address stays in use for a number of days after
it is handed out, it is likely to be permanent.  The longer an address stays in
use, the more likely it will stay in use.

In any case, a single server should be able to handle both cases effectively
with some tuning.

Drew
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 13:13:46 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        ddp+@andrew.cmu.edu
Cc:        deering@pescadero.stanford.edu, mills@udel.edu tcp-ip@sri-nic.ARPA
Subject:   Re: dynamic IP assignment

> I think this issue only comes up when you have a small number of addresses
> available but you have a high "churn" (Millspeak).  When you have a large
> number of addresses available, you can be very conservative with recycling
> them.  I.e. if you have a sufficient number of addresses available, you may be
> able to wait 1 week before you have to recycle any particular address.

    I believe most of us will have a small number of addresses available
in the particular network or subnet in question.  Certainly this is already
true at some sites.  So churn may well be high.  At BBN we've already been
bitten by people assuming addresses don't get re-assigned quickly and
briefly re-using an address they'd recently given up.  I'd certainly hate
to design a system that assumed churn was low.

> It may also be possible for the server to figure this out for itself using some
> heuristics. ...  the server may be able to figure out whether it is
> transient or permanent.

    But why not let the server *know* in the first place.  All this says
is that, using some heuristics, we may be able to reduce the probability of
confusing a transient address with a permanent one.  Well, if we used
separate protocols (or simply set a bit in the same protocol) for
permanent vs. transient addresses the probability of confusing them would
be nil (just have one pool of transient addresses and separate pool for
permanent addresses -- voila, no goofs).

    Going further afield -- I notice we seem to have skipped Dave Mills'
idea.  Dave -- how well could your system cope with, say 400 IETFers all moving
their PCs to Ann Arbor in a matter of eight hours (allowing for different
plane schedules)?  My initial reading of your note suggests that we'd
be increasing the number of routes in the Internet by 100% (we've now
got about 475 active networks) and that sounds like it scales poorly.
Did I misunderstand your idea?

    Finally, I've gotten several private notes from people to the effect
that they are working on address assignment protocols.  I'd really hate to
see us develop more than one...

Craig
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 07:52:12 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.protocols.tcp-ip,comp.dcom.modems,comp.dcom.lans
Subject:   SLIP, Telebits, header compression

[ This has turned into a summary of what I said at the Interop 88 SLIP BOF.
  If you were there and heard me, you don't need to read this. --vix ]

[ The IP/TCP explaination is fast and loose, intended for comp.dcom.modems
  readers, and is probably wrong in ways that many comp.protocols.tcp-ip
  readers would love to explain.  I am, for example, calling everything a
  "packet" even though sometimes I mean "frame" and sometimes I mean
  "segment" and sometimes I really do mean "packet".  If you must explain,
  please do so by mail.  --vix ]

Before I start, a disclaimer: I hack SLIP for fun, not for work.  Although
we may use some of my work here at WRL, I am _not_ working on a DEC product
and I am _not_ speaking here as a representative of DEC or anybody else.
I'll repeat this at the end of this article since many novices to e-mail
seem to want to quote people without maintaining context.  Please try to
avoid that; if you don't include my disclaimer when quoting me, please don't
include my name or any other identification, either.

idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes:
# I managed to get SLIP working using direct-connected Trailblazer modems
# at 19200 bps between two VaxStation 2000 Ultrix 2.0 systems using some
# 4.3bsd SLIP source from the net, slightly modified to compile and fit
# into our Ultrix binary distribution.  Interactive response (via rlogin
# over the SLIP line) was abysmal.  Bulk data transfer (via rcp) was not
# bad for large files.  I was going to test interactive response with
# data compression mode off, to see if that helped, but I haven't done
# that yet.

I have not yet tried it with data compression _on_, but with data compression
_off_, I get barely tolerable echo-delay for interactive things like rlogin
and telnet, and I get about 1000 bytes/sec with rcp or ftp.  Neither one is
impressive, considering that I'm talking to the modem at 19,200 baud, and
when I set up a 19,200 baud hardwired connection I have much better inter-
active response and get about 1700 bytes/sec on bulk file transfer.

I'll finish answering this other note and then add something original...

# Ultrix 2.4 seems to have a much nicer dial-up SLIP capability via an
# /etc/sliphosts file and login accounts that run /etc/slattach.  Haven't
# tried that yet.

The story I hear is that Ultrix 2.4 will never be released, and that Ultrix
3.0 is coming real soon now.  The dial-up SLIP stuff works extremely well;
once you grok /etc/sliphosts, you can get two systems to talk to eachother
by saying "slattach remotename" and all the dialing and logging in and etc
just happens.  Getting /etc/sliphosts and /etc/hosts right took some doing,
but maybe I'm disadvantaged since I didn't know what it was supposed to do
for me and I was used to doing it by hand.

One thing that _doesn't_ happen in Ultrix 3.0 SLIP is _dynamic dialup_.  This
is hard to even design properly, since you don't want a stray broadcast
packet to start all your modems dialing their neighbors.  Among other
problems.  But the ability to get the connection set up without having to
use "tip" and ~^Z and all that stuff is pretty nice.  Unfortunately it uses
the Ultrix /etc/acucap stuff, so it's largely nonportable (even if it were
releasable, which it probably is not).

Anyway, SLIP performance on the Telebits is Not Good, so let's talk about that
next.  The problem is basically that the Telebit is a half-duplex modem.  This
is what makes the UUCP spoofing so useful -- if the uucicos had to wait for
their ACK packets to get all the way back from the other side, they'd wait a
very long time indeed.  The Telebits have to "turn the line around" whenever
they have to send data in the "other" direction.

Well, wait, that's not quite right.  I've been told that there's this little
"ping pong packet" that the Telebits invisbly exchange, and that if the data
that wants to go in the "other direction" can fit in this invisible packet,
it can go without turning the line around.  I've been told that the amount
of data that will fit is "around 11 bytes".  I was unable to ascertain how
many bytes (or how much time) had to pass in the "forward" direction before
one of these "ping-pong packets" would be sent; basically I don't know what
ratio of forward/backward data will work and what ratio will not work.  From
my discussion with the expert, I gathered that that's not the right question.

I'm assuming that I can send 11 bytes backward for every 256 bytes I send
forward, since the PEP packet size is 256 bytes.  This would explain why the
UUCP spoof was needed, since UUCP likes to send about 64 bytes forward per 4
backward.  (Or something, somebody correct me if I'm wrong.)  With a SLIP
MTU of 1006, one assumes that if there are large FTP or RCP packets on in
the forward direction, an occasional TCP ACK in the backward direction might
get through without making the modem stop and turn around.  You can
definitely see the modem turning around, which is why the 1000 bytes/second
figure stunned me so much -- the modem was idle about half the time,
according to my eyeballs, and _still_ got 1K/sec.  Amazing device.

Anyway, 11 reverse bytes is not enough, not even for 1006 forward bytes.  So,
it's time to talk about S L I P H E A D E R C O M P R E S S I O N.  Before I
get going, I'd better explain that I'm a hacker and understand this stuff
only trivially.  But: your average IP packet has a 20 byte header, followed
by "data".  If the packet is TCP, there's (on average) another 20 bytes of
header, followed by "data", which, again, will depend on the protocol being
used.  Telnet, FTP, and rlogin all use TCP.  Note that there is therefore an
overhead of _40 bytes_ on the average Telnet/rlogin keystroke, unless you
batch them, which can cause unacceptable echo delays if you get too
ambitious about waiting for more things to add to the current "batch".

A TCP ACK packet is 40 bytes even.  There's no data area, it's all in the TCP
header.  One of these goes back for every RCP or FTP or Telnet or rlogin
data packet that gets sent out.  Note that in the worst (and also most
common) case, Telnet/rlogin cause 41 bytes to go in the forward direction
and 40 bytes to come back a beat later in the reverse direction, for every
character that you type.

The headers are too big.  Too big for the Telebit ping-pong packet, anyway.

They can be compressed.  Someone (Van again?) found that most of the headers
don't change from one packet to the next, in a single virtual connection.
The trick to header compression is to "diff" a packet against the last one
you sent and only send the parts that have changed.  You also have to send
a bitmap of the bytes you're sending.

A SLIP packet has a framing character at the front (sometimes) and a framing
character at the end.  These tell the remote SLIP driver where the packet is,
and they are non-negotiable overhead.  That leaves about 9 bytes ("about" is
the way the Telebit expert explained it, don't get mad at me") before the
modem has to turn around to get the packet across.  A TCP ACK is normally
40 bytes.  I don't know yet but I am hoping that the headers are full of
enough repeated information that these 40 bytes will fit in the 9 I have
available.  Remember that we've got to send a bitmap of changed header bytes
as part of each packet.

It sounds hopeless.  Like many hopeless-seeming things, it may work anyway,
depending on whether I can get more steam out of compression by looking at
bigger fields and getting more out of each bitmap element.  Or it may work
well enough as it is.

One thing I'm toying with (mentally; right now I'm just trying to keep the
system from crashing it :-)) is maintaining several different packets to
"diff" against so that if two virtual connections go on at the same time, it
won't go immediately to worst-case.  Details of this are presently out of
control; don't ask.  Suggestions (by mail!) are welcome.

I'll let you all know how it goes.
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 12:59:54 EST
From:      Greg Mouning <GAM%YALEVM.BITNET@MITVMA.MIT.EDU>
To:        Listserver <TCP-IP@SRI-NIC.ARPA>
Subject:   Help.
Help.
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 08:22:20 GMT
From:      alecd@extro.ucc.su.oz (Alec Dunn)
To:        comp.protocols.tcp-ip
Subject:   Problem configuring CMU TCP/IP for VMS

I have recently installed the CMU TCP/IP v6.3 package on our
VMS machines.  It works fine and is great value for money.
The only problem is the installation notes give very little
information on the various configuration files. The one I'm
stuck on is sys$library:expand.txt.

When internet mail for a vax user arrive, the CMU software
correctly receives it, and then promptly "forwards" it into 
the void using the internet protocol!

Does anyone know how to tell the system to forward incoming
mail via plain VMS mail?

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 15:47:20 EDT
From:      dzoey@terminus.UMD.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Looking for FTP hosts to test against.
Hello, I'm looking for an FTP server that supports BLOCK mode
to test my ftp client against.  I have been having trouble locating
one locally here at U of Md. that doesn't require you to be
in type EBCDIC (which I don't support). 

I remember Mr.  Lloyd saying he had a complete FTP server
implementation, but I have been unsuccesful in sending mail to him. 


                        Thanks for any pointers,

                        Joe Herman
                        PC/IP project
                        U. of Md.

dzoey@terminus.umd.edu
--
"Everything is wonderful until you know something about it."

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 16:33:52 EDT
From:      map@gaak.LCS.MIT.EDU (Michael A. Patton)
To:        ddp+@andrew.cmu.edu
Cc:        craig@nnsc.nsf.net, deering@pescadero.stanford.edu, tcp-ip@sri-nic.arpa
Subject:   dynamic IP assignment
   Date: Tue, 11 Oct 88 12:28:21 -0400 (EDT)
   From: Drew Daniel Perkins <ddp+@andrew.cmu.edu>

   ...  The server should probably keep records on when addresses were
   allocated, when they were last in use, rate of address allocation,
   etc.  For any particular address, the server may be able to figure
   out whether it is transient or permanent.  If an address stays in
   use for a number of days after it is handed out, it is likely to be
   permanent.  The longer an address stays in use, the more likely it
   will stay in use.

It occurs to me that this is the right approach, in fact rather than
making a single binary decision perhaps the best is to use a formula.
E.g. hold the address for a time period that is proportional to the
time it was in active use, probably with upper and lower limits.  This
essentially gives a continuous scale of ``permanance'' rather than a
simple yes/no.

An even better heuristic might be achieved by using the data not to
declare an address ``recycled'' but to rate each of the addresses in
it's set of assignable addresses based on these numbers and then pick
the ``best'' right now.  The rating could be a fairly simple formula
so that the time to evaluate it would be minimal.  Note that there is
no reason to keep track of reuse rate explicitly, it's used to drive
the system.  Only the assigned and last active times are needed for
each address.

   In any case, a single server should be able to handle both cases effectively
   with some tuning.

The scheme I just described tunes itself to the size of the assignable
address space, and the reuse rate you give it.  The system manager
would have to tune the entire system by giving the assigner a
sufficient supply to deal with the expected load, but failing that
this scheme appears to degrade gracefully.

   Drew

Mike Patton, Network Manager
Laboratory for Computer Science
Massachusetts Institute of Technology


P.S. Now, of course there's the question of interfacing this to a
nameserver if I want to be able to have my hosts named.  I guess you
could consider having the address registered to a name to be
``actively using'' the address, and deal with timeouts in the
nameservers, too.
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 13:36:27 GMT
From:      smsdpg!rht@uunet.uu.net  (Randy Thompson)
To:        tcp-ip@sri-nic.arpa
Subject:   Intelligent Token Ring Card w/ TCP-IP


I am looking for a token ring network adapter for PC class machines
(both AT bus & Microchannel) that has TCP/IP resident on the card.  

Does such a card exist? 

Thank you in advance for your help!

randy



 /--------------------------------------------------------------------------\
||    Randy Thompson                   ||                                  ||
||    /SMS Data Products Group, Inc.   ||                                  ||
||    12379A Sunrise Valley Drive      ||    UUNET:  uunet!smsdpg!rht      ||
||    Reston, Va 22091                 ||    Voice: 703/648-9400           ||
 \-------------------------------------------------------------------------/
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 14:06:53 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.protocols.tcp-ip,comp.dcom.modems,comp.dcom.lans
Subject:   Re: SLIP, Telebits, header compression

In article <12@jove.dec.com>, I wrote a long article about SLIP header 
compression and the things I thought were the state of its art.  Silly me.

I have been shown the light; humbled; brought up short; in other words, I
have received some mail from Van.  It seems that in a message to this forum
some months ago, Van explained what _he_ had done with header compression,
which was so far advanced of what I was planning to do that I am now sitting
in the middle of my office counting my fingers and toes to see if I still
have that much mental capacity :-) :-)...

Anyway, disregard previous message.
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 16:30:51 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP

In article <185@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>Is anyone aware of any implementations of NetBIOS over TCP/UDP,
>as specified in RFCs 1001 and 1002 ??  (I posted this to the
>comp.protocols.ibm newsgroup last week and got zero response.)

I believe that Excelan, FTP Software and Ungermann-Bass do. That list
could be wrong and it's probably not all-inclusive.

>Also, if such a beast exists, does it have a *reasonable*
>user interface, as opposed to the PC NetBIOS interface,
>where everything is done through a single function call with
>a single argument (a pointer to an Ncb) ?

Sorry, but that IS Netbios. The programming interface defines the
semantics of the network operations and how you call them, and that's
it. Netbios is the programming interface, not what's under it.

RFCs 1001 and 1002 define some protocols that allow the programming
interface to be implemented on top of TCP/IP. These protocols are
necessary because the semantics of NETBIOS do not map well to the
semantics of TCP and UDP, particularly in the area of names.
-- 
			- john romkey
UUCP: romkey@asylum.uucp		ARPA: romkey@xx.lcs.mit.edu
 ...!ames!acornrc!asylum!romkey		Telephone: (415) 594-9268

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Oct 88 17:15:11 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP references (Comer review, reposted)

Sorry to everyone who's seeing this for the second time, but with the
fall influx of new people, and some of the recent uncritical gushing
over the Comer book [which is good and useful, but far from perfect],
I thought it worth reposting this:

----------
Subject: review of Comer TCP/IP book
Message-ID: <1988Jul8.012631.15892@utzoo.uucp>
Date: Fri, 8-Jul-88 21:26:31 EDT

I acquired a copy of "Internetworking with TCP/IP" at Usenix and finished
reading it on assorted airplanes.  I have sufficiently mixed feelings
about it that I think it worthwhile to review it in detail.

Background:  I'm not a real TCP/IP guru, but might qualify as an apprentice
guru.  I learned about it originally by reading the RFCs (gak) and I work
on and maintain our local version, a variant of the KA9Q implementation.
I can't claim to be intimately familiar with all the details or to have
read the whole Protocol Handbook, but I know the outlines of most of it
and have combat experience with some of it.

The book emphasizes overall understanding of the protocols, although it
does cover a fair amount of detail.  The really fine points are punted to
the RFCs, for the most part.  It is meant to be useful as both a textbook
and a reference book, and generally strikes a happy medium.  It contains
coherent discussions of a number of issues that are hard to find in one
place otherwise.  Its appendix of implementation hints is worth the price
of the book all by itself, if you're going to be implementing TCP/IP.  It
is competently produced, with few botches (although some that remain are
serious, e.g. errors in RFC numbers in some of the Further-Reading sections
and a disastrous typo in Figure 4.1, the ONLY place where the decoding of
Internet addresses is explained precisely).

I wish I could recommend this book unreservedly.  Alas, I can't.

The fact is, this book has serious flaws.  First, most serious, and quite
possibly the cause of the others, is that it appears to have been put
together hastily as an expansion of a knowledgeable professor's skeletal
lecture notes.  The result is that while individual sections are okay,
they are not tied together well.  In particular, there are many cases
where something is referred to as if it had already been explained, when
in fact the explanation comes later or is entirely missing.  The appendix
on the Berkeley interface refers offhandedly to the fact that a connection
is characterized by both its endpoints, and hence more than one connection
can be active on the same port -- but this important and subtle concept is
NEVER discussed in the text proper!  The discussion of the name server
protocol suddenly starts using variable-length strings without explaining
how they are encoded... that comes later, in the section on the compressed
name format!  The chapter on ARP never does explain the PROTOCOL field.
These are not isolated examples; this sort of thing happens continually,
and makes the book very frustrating to read sequentially.  I already knew
enough to make this only an aggravating nuisance; a real novice would, I
think, find it very troublesome without external help.

Okay, so this hurts it as a textbook.  Is it useful as a reference book?
Same answer:  yes and no.  The trouble with it as a reference book is that
too many details are left out.  There are several references to the Karn
algorithm for RTT estimation, but it is never discussed; describing it
precisely and giving an outline of why it's good would take only a page
or two.  The three-way handshake for TCP connection establishment is
explained, but the handshaking for closing a connection is never really
explained; the state diagram from RFC 793 would take only a couple of
pages to show and tersely explain, but this is never done.  The urgent
pointer is brushed off in one sentence that does not really explain how
it works.  While it isn't really realistic to expect a book of this size
to replace the Protocol Handbook, this book would be an order of magnitude
more useful as a reference if it included 10% more detail.

A lesser, related problem is inconsistent level of detail.  The lower-
level protocols are explained in considerable detail, while the high-level
ones are crowded into a chapter or two that permits only a hint at the
overall flavor of a few of them.  The level of detail is inconsistent
even within discussions, with detailed message formats sometimes given
and then accorded only a quick hand-waving explanation.

One last annoyance in using the book as a reference is that the textbook-
oriented exercises at the end of each chapter sometimes raise important
points that one would hope a reference book would discuss more explicitly.
The implementation-hints appendix resolves some, but not all, of these
loose ends.

Overall, this book would be acceptable as a textbook for a course taught
by a knowledgeable professor who can fill in the gaps and smooth down the
rough edges, or as a self-study text for a bright student who knows
something about the topic already and has access to a copy of the Protocol
Handbook.  I cannot recommend it for self-study in general, and as a
reference its usefulness is limited.  It seems to me that many of the
problems arise from it being prepared in haste.  I would look forward
eagerly to a second edition, slightly expanded, thoroughly revised for
completeness, coherence, and consistency, and preferably tested on an
unassisted novice before publication.  That second edition could be a
truly superb first book on TCP/IP; the first edition is rather mediocre,
and is the clear choice only because there is no other.  It's really
unfortunate that the publishers are succumbing to the computer builders'
bad habit of letting their customers debug their products.

All that being said, this book *is* a lot better than nothing.  I learned
quite a bit from it, despite the problems.  If you are considering buying
it, either for yourself or a course, I would say "go ahead... cautiously".
----------
-- 
The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 21:18:07 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: dynamic IP assignment

[I think this discussion needs some irreverent irrelevance, so...:]

Curiously, `dynamic address assignment' is trivial in an XNS
environment.  Xerox Network addresses consist of unique 48 bit host
numbers and 16 bit network numbers.  Imagine that the machine has the
48 bit number wired into its backplane.  If the machine is connected to
an Ethernet, it uses this as an Ethernet address; its network number is
then a logical `cable number'.  If it is on dialup connections, it
borrows the network number(s) from the router(s) it can reach by these
dialups.  Its host number is fixed (wired into the backplane, remember?).
The only part of its address that is dynamic is the network number.

Some other things fall out of this naturally:

A machine can be a packet forwarder if and only if it has multiple
addresses; it can forward between any two of its networks.

For hosts, routing is easy.  If the network number is known and is the
same as (one of) your own, send it on that network.  If it is unknown,
or if it is not the same as yours, send it to a `gateway' (router).
(For routers, routing is hard.  No surprises here.)

What this really does is point up a particular problem in IP: host
addresses are too closely tied to host locations.  My class B network
umdnet machine `imladris.cs.umd.edu' can be put anywhere on umdnet, but
nowhere on ucb-ether (at least not without Mills' `tunnels').  The
XNS scheme has its advantages....

[Hm, not as irrelevant, nor as irreverent, as I had hoped.  Ah well.]

Chris

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 88 23:39:56 GMT
From:      stuart@speedy.cs.wisc.edu (Stuart Friedberg)
To:        comp.protocols.tcp-ip,comp.protocols.misc,sci.research
Subject:   Request for Protocol Test Tools

I am running a project to design and test an experimental functional
extension to the TCP/IP protocol.  We will be concentrating on the
connection setup/teardown sub-protocol, leaving the reliable
transmission sub-protocol pretty much alone.  We would like to use
existing software during the test phase, so I am now looking for
test (exhaustive) or verification (deductive) tools which have been
applied to un-modified TCP/IP by other workers.

Because we want to test the protocol before implementation, network
protocol exercisers won't be of much use, but we could use any type
of mechanical protocol testing that accepts a protocol description or
simulation as input.

This would be a good opportunity for verification specialists to see
their tools used by "practitioners", and to get feedback about adapting
the tools to a related, but different, problem.  If in doubt about the
utility of your tools on our problem, please drop me a note.  We'd
rather hear from you than not.

We can pay a nominal fee for software duplication and distribution, and
appropriate credit will be given to tool providers in our project
reports.

Stuart Friedberg	stuart@cs.wisc.edu	(608) 262-0664
Department of Computer Science
1210 West Dayton Street
University of Wisconsin - Madison
Madison, WI  53706

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 01:11:10 GMT
From:      sob@harvisr.harvard.edu (Scott Bradner)
To:        comp.dcom.lans,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   HSDN RFI from Harvard


On Oct 31st 1988 Harvard University will be releasing a Request For Information
(RFI) concerning a proposed High Speed Data Network (HSDN) that has as its
purpose linking together LANs in many of Harvard's 500+ buildings and to link
these LANs to a number of external networks, (NSFNET, ARPANET, BITNET etc).

The RFI also makes the assumption that a Network Operations Center (NOC) will
be required and that the management tools that are used for the NOC to manage
the HSDN itself will also be used to manage many of the building LANs.

The RFI addresses the HSDN hardware and software, the interfaces between the
HSDN and the LANs, the hardware and software for the NOC, facilities for
connections between the HSDN and the ISDN part of the new Harvard phone system,
and hardware and software for selected services that will be HSDN based.

Harvard would like to get the widest distribution for this RFI and to get as
many responses to all or part of the RFI as it can.  The RFI will be made
available for anonymous FTP and we will send a copy to any firm that requests
one.

We welcome any and all comments on the RFI from all sources.

The reason for a posting at this time is to get the names of firms that would
like to get a copy of the RFI sent to them. (All firms that get a copy of the
RFI from us will get copies of any questions that other firms ask and our
responses.)

If your firm would like to get a copy of the RFI please send me the address
to send it to.

	Scott Bradner
	Harvard University			       sob@harvard.harvard.edu
	33 Kirkland St.			or
	Cambridge, MA				       sob@harvunxw.bitnet
	02138

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Oct 88 10:28:47 PDT
From:      postel@venera.isi.edu
To:        TCP-IP@sri-nic.arpa
Subject:   Bad Mailboxes Violate Rules
Hello:

It is the responsibility of the system (host computer, mailer program, etc)
that transmits a computer mail message into the TCP/IP Internet to follow
the rules for the format of messages.  It does not matter if the message
originated on some other host and the messages is being forwarded or relayed.
All messages sent on the Internet must follow the rules of RFC-821 and RFC-822.

In particular, all address fields in message headers (From, To, CC, Reply-To,
etc) must contain mailboxes that will actually work in the Internet.  There
has been a noticable increase recently in violations of this rule, especially
in mail relayed from UUCP land.

Specifically, messages have been received at ISI with mailboxes like:

	westine
	cag@iwnip.uucp
	erik@mpxl.uucp
	fred@trwrb.uucp
	tran@saigon.uucp
	venera!westine@aero.uucp
	ucbvax!decvax!motcoh!mark@hplabs.uucp
	sybase!sun!versatc!saigon!tran@trwrb.uucp
	@iwtsl.uucp:iwlcs!att!venera.isi.edu!ietf-request

These are not acceptable addresses in the Internet, and the hosts that send
or relay messages with such addresses into the Internet are violating the
Internet protocol rules.

--jon.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 05:30:17 GMT
From:      george@ditmela.oz (George michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: what is dynamic IP address assignment

as a TCP novice I am probably way out of line here so please forgive me.

I see some problems with this area.

	(1)	what is the scope and validity of a temporary assignment
		within the INTERnet at large?

	(2)	what is the threshold above which the net cannot cope with
		dynamic assignment?

some peoples suggestions about what dynamic IP address assignment offer 
seem (to me at least) to float functionality which requires propagation
of the new address "binding" out into the world. -If I wanted to take
a portable IP-using box around the country, and somehow get an IP address
at <new local point of attachment> and somehow propagate that back to
<my mail store host> and thus read my mail, I'd be doing things like that
wouldn't I?

-ok, one can come up with back-of-envelope schemes which support in one
persons phrase "reasonably small numbers of people doing this" but the
network-at-large has 2.5Million+ end-users. 0.1% of this is really quite
substantial traffic and address space. yes/no?

fairly simple schemes where a pool of IP addresses are reserved for new
machines already exist, Appletalk-ethernet gateways being examples. 
does one connect, grab <first-free> subaddress, propagate, free, disconnect
or what? how do you adjust the life of a temporary binding to cope with
variable delay across the internet as you move around from point to point?

If I've mis-understood the intent, do please put me right!

	-george

-- 
        George Michaelson, CSIRO Division of Information Technology

ACSnet: G.Michaelson@ditmela.oz                      Phone: +61 3 347 8644
Postal: CSIRO, 55 Barry St, Carlton, Vic 3053 Oz       Fax: +61 3 347 8987

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Oct 88 16:32:22 PDT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        tcp-ip@sri-nic.arpa
Cc:        tencati%jplgp.span@VLSI.JPL.NASA.GOV
Subject:   Re: TCP/IP over DECnet ?
> Contact Ken Adelman (KEN@WARBUCKS.AI.SRI.COM).  He has written a TCP/IP
> over DECnet program.	This works in conjunction with SRI's Multinet TCP/IP
> I believe..

    My correct address is ADELMAN@TGV.COM.

    Indeed I've written DECnet over TCP/IP as well as TCP/IP over
DECnet for VMS.  MultiNet continues to be available from SRI
International and for those interested in 'big vendor' support, it is
now available from Excelan.

						    Ken
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 11:37:47 GMT
From:      stevens@hsi.UUCP (Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP

In article <957@asylum.UUCP>, romkey@asylum.UUCP (John Romkey) writes:
> 
> Sorry, but that IS Netbios. The programming interface defines the
> semantics of the network operations and how you call them, and that's
> it. Netbios is the programming interface, not what's under it.

OK, my next question is "what is the purpose of NetBIOS over TCP" ?
I see two answers:  (1) To take the existing horde of NetBIOS
applications and run them on other systems;  (2) To provide another
communication interface for a programmer.

The problem with (1) is that I'd guess 99.9% of all existing NetBIOS
applications are written *specifically* for the IBM PC and that a
vast majority of them contain a lot of assembler code.  That means to
take the source for, say, a file server, and port it to a UNIX VAX
that supports "NetBIOS over TCP" is non-trivial.  If there are
existing applications in C, for example, then does there exist a
standard C interface to NetBIOS that can be used in different
environments (i.e., both on a PC with "real" NetBIOS and on a systems
with NetBIOS over TCP) ?

The problem with (2) is who needs it ?  Wanting to preserve the
NetBIOS "user interface" seems like emulating the old OS/360 IO
Control Blocks using the Unix i/o interface.  Yes, it can be done,
but why ?  IBM has nicely given us a similar interface to TCP/UDP/IP
under VM, where everything happens through a single function.  That's
an interface that's not worth preserving, and it is non-trivial to
port any of our TCP applications from a BSD VAX using sockets to this
beast.

As I understand the interface for NetBIOS, you get a single function
that takes a single argument (ptr to an NCB struct) and everything
happens from there.  It would seem simple to add a better user
interface on top of that, but it would also be nice if that interface
were standard across different vendor's implementations.

It seems I'm missing something in the reasoning behind wanting
NetBIOS over TCP, but given that vendors exist that sell this as a
product there must be a need for it.  Can someone shed some light on
just what people are doing with it ?  Thanks.

	Richard Stevens
	Health Systems International, New Haven, CT
	   stevens@hsi.uu.net
	   ... { uunet | yale } ! hsi ! stevens

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 14:33:48 GMT
From:      jim@umigw.MIAMI.EDU (jim brown)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Availability of CMU TCP/IP patches for SLIP/X.25/Decnet in US

[food for the line eater]

This announces the availability of patches to CMU TCP/IP to implement
SLIP and IP tunnelling over X.25 and Decnet.  The files may be copied
from UMIGW.MIAMI.EDU by anonymous FTP.

Jim Brown, University of Miami (home of the Hurricanes)
[send mail to jim@umigw.miami.edu]
-- 
Jim Brown, University of Miami (home of the Hurricanes)
[send mail to jim@umigw.miami.edu]

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 15:54:32 GMT
From:      dave@arnold.UUCP (Dave Arnold)
To:        comp.protocols.tcp-ip
Subject:   Re: Search for TCP-UUCP

(Doug Nelson) writes:
> > I am looking for a UUCP program which will run under TCP-IP
> > on internet,
> > instead of via phone line.
> 
> Why do you need/want UUCP?  RCP exists for exactly this purpose.
> 

RCP is for LAN use, and doesn't provide queueing capabilities.

What if your APPLICATION SOFTWARE wanted to send a file to a remote,
but the transmission link is down?  RCP would immediately fail.  With UUCP
it would sit in the queue until the link is brought back up, and the
cico daemon kick started.

We use UUCP over TCP/IP over Ethernet.  Our vendor supplied us with a
outbound virtual tty device.

Say the device is /dev/ttyT8...

typing $ cu -s9600 -l/dev/ttyT8 dir

would connect you to the device, then enter a host name in
/etc/hosts...

the virtual tty device then creates a rlogin session with the host
you entered (which is not echoed), and you magically get a login:
prompt.  With this approach it is trivial to get uucico to place
an outbound call.
-- 
Dave Arnold (dave@arnold.UUCP)
Work: Volt Delta Resources     Phone: (714) 921-7635
Home: 26561 Fresno street,  Mission Viejo, Ca  92691

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 16:49:23 GMT
From:      jle@ece-csc.UUCP (Jamie Evans)
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   tcp-ip terminal servers



I am currently interested in purchasing a tcp/ip terminal server for 
the department here at Virginia Tech. We currently have a network
consisting of a DEC 3500 and 2000 running Ultrix, 30 Macintosh A/UX 
systems, a Sun and numerous AT&T pcs. We would like to have a tcp/ip
terminal server for our terminal room and to allow faculty to call
in from home. I am interested in any vendor information/prices/contacts
that anyone could offer. I am currently accessing USENET from NC State
so if you have any suggestions of what servers are better than others, 
suggestions, etc. please let me know. 

I can be reached via e-mail at jle@vtopus.cs.vt.edu, through Applelink
via U60 or by phone at 703-961-6931.

Thanks in advance....


	-Jamie Evans-
	Director of Computing
	CS Department
	Virginia Tech

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 16:51:06 GMT
From:      barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett)
To:        comp.protocols.tcp-ip
Subject:   Broadcast RPC question

We have a problem on our network with diskless Suns running SunOS 4.0.
At times they are unable to boot, due to some condition on our
network.

I have been working with Sun on this for several months and still do not have
a solution OR workaround.

Our environment:
	Company wide network:	3.0.0.0	(ge-net)
	Local Subnet:		3.1.4.0	(ge-crd-net)
		Netmask:	255.255.252.0
		Broadcast:	3.1.4.0
	About 800 hosts in the local subnet
	Type of systems on our network: You name it. We got it.

When a 4.0 diskless client boots up, it does a broadcast RPC, using UDP,
to the 3.0.0.0 network.

Since Sun hasn't fixed the problem yet, I am trying (in the meantime) to get
the other vendors to fix their software. (Desperate times indeed!)

However, one DEC representitive has told me that Sun is doing the
Wrong Thing, and it's not DEC's problem.

Here are the packets that *I Think* are causing the problem:

	Bruce G. Barnett

======================DATA FOLLOWS=====================

Example packet send from diskless client (via etherfind)

UDP from grymoire.1023 to ge-net.sunrpc  108 bytes
 ff ff ff ff ff ff 08 00 20 01 9c 27 08 00 45 00
 00 80 00 00 00 00 ff 11 b0 49 03 01 05 23 03 00
 00 00 03 ff 00 6f 00 6c 00 00 1f 73 91 f3 00 00
 00 00 00 00 00 02 00 01 86 a0 00 00 00 02 00 00
 00 05 00 00 00 01 00 00 00 18 1f 74 bb f0 00 00
 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00
 00 01 00 00 00 00 00 00 00 00 00 01 86 ba 00 00
 00 01 00 00 00 01 00 00 00 14 00 00 00 01 00 00
 00 03 00 00 00 01 00 00 00 05 00 00 00 23

Typical response from several machines:

ICMP from ge-net to grymoire dst unreachable bad port
  bad packet was: UDP from grymoire.1023 to ge-net.sunrpc  108 bytes
 08 00 20 01 9c 27 aa 00 04 00 60 10 08 00 45 00
 00 38 02 dc 00 00 ff 01 ad c5 03 00 00 00 03 01
 05 23 03 03 a8 6c 00 00 00 00 45 00 00 80 00 00
 00 00 ff 11 00 00 03 01 05 23 03 00 00 00 03 ff
 00 6f 00 6c 00 00
-- 

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 19:58:46 GMT
From:      sandy@TOVE.UMD.EDU (Sandy Murphy)
To:        comp.protocols.tcp-ip
Subject:   simultaneous connections

I have been studying various transport protocols and the services they provide,
especially TCP and ISO TP.  I have a question concerning one feature in particular.
 
In TCP, simultaneous attempts by two hosts to establish a connection will result in one
connection.  In ISO, the result would be two connections.  I am told that some time ago
(more than one year?) there was a discussion of the advantages of / need for the TCP
method of handling simultaneous connections.  Does anyone know of situations or
applications that need or take advantage of this facility/feature/peculiarity of TCP?
If and when we go to ISO will anything be broken?

sandy murphy (sandy@tove.umd.edu)

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 88 21:30:25 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   Re: tcp-ip terminal servers

The two leaders, in my opinion, are ENCORE and CISCO.  They seem to trade
back and forth as to functionality.  The ENCORE probably provides more
user facilities (like the ability to get parts of EMACS in the terminal
servers).  CISCO wins out on the fact that you can put 96 lines in a
single box.  This is handy for large scale central modem banks or bign
terminal rooms (the big box turns out to be much cheaper than several of
the smaller ones).

There are other units available from Bridge, UB, Micom, Xyplex, and Develcon.
These are probably lagging slightly behind the leaders in general niceness
and bang for the buck.

-Ron

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 1988 01:57-EDT
From:      CERF@A.ISI.EDU
To:        sandy@TOVE.UMD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: simultaneous connections
In systems which operate a distributed, common algorithm which does
not use the master/slave or caller/callee model, the TCP was specifically
designed to allow to processes to reach each other concurrently and
wind up with a single connection. The ISO model tends to be master/slave.

I do not know whether any distributed systems in the Internet take 
advantage of the TCP design feature but at the time of its design,
TCP held symmetry to be a highly valuable characteristic.

Vint Cerf
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 88 05:57:00 PDT
From:      Doug Blair <doug@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   re:  PC support for 3C505

Wollongong's WIN/PC product (the MIT PC stuff with considerable
enhancements) supports the 3C505 card.

Doug Blair, WOllongong
DOUG@TWG.COM

"If I don't know what I'm saying, I'm sure they don't."

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Oct 88 09:42:24 PDT
From:      braden@venera.isi.edu
To:        sandy@tove.umd.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  simultaneous connections

Sandy,

Like so many issues in protocol and operating system design, the question
of simultaneous opens in TCP seems to be a philosophical issue (if you agree
with it) or a religious issue (if you disagree with it).

I believe that the philosophical [sic] arguments in favor of the TCP
simultaneous open were as follows:

1.  Never introduce unneeded asymmetry into a system.  [The exact same
     philosophy led to the manifest symmetry of Telnet, as opposed to
     the assymmetry of X.29.]
     
2.  The transport layer should not enforce a semantic model on the
     application.

     The idea here is that the transport protocol should not provide
     support for only the client-server model in the application layer;
     it should also support a model of two peer servers connecting to
     each other.

As a practical matter, you can do anything with the client-server model
that you can do with a more general model, and in fact all Internet
application protocols really do use the client-server model.  There are
several reasons for this; one is that the client server model seems
conceptually simpler than co-operating peers, and (more importantly) the
major Internet protocols where all originally ARPAnet protocols, running
on top of the NCP protocol whose connection establishment was (blatantly)
asymmetric.

The only application I have ever seen that used the simultanous open of
TCP was the MSG interprocess communication mechanism of the National
Software Works (NSW).  Each host had an MSG agent, and there was a single
virtual circuit between any pair of MSG agents that needed to
communicate. These connections were opened as needed and closed when
idle.  The simultaneous open solved the race condition of two agents
needing to open a connection to the other at the same instant.
Perhaps others have seen applications.  However, although the TCP
protocol supports simultanous opens, I don't think that many implementations
support it.  The problem is in the application/transport interface; an
application needs to be able to convert a passive open to an active open,
but most interfaces don't allow this.

Bottom line: the simultaneous open of TCP is probably not a big win from
a practical viewpoint, but it has a certain elegance that is pleasing.

Others may disagree, and I expect they will.

Bob Braden
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Oct 88 09:49:39 PDT
From:      Mary Stahl <STAHL@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        stahl@SRI-NIC.ARPA
Subject:   Disclaimer about recent msg re: class A logical addressing

Since I've gotten a few questions from people about the following
message, I wanted to state for the record that the person who sent it
to the TCP-IP list has confused me with someone else (see asterisks
below).  I have no recollection of ever having talked to anyone on the
subject of Class A logical addressing "horror stories".  In fact, I
don't know any such stories.  - Mary

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

From: cochise!cvincent@usacec.arpa (Vincent)
Message-Id: <8809182058.AA04394@cochise>
To: alamo%tcp-ip-RELAY@SRI-NIC.ARPA
Subject: RE: Logical Class A Addressing
Cc: hassler@asd.wpafb.af.mil
Date: Sun Sep 18 13:58:34 1988
ReSent-Date: Tue, 20 Sep 88 15:14:59 PDT
ReSent-From: Lynn Gazis <SAPPHO@SRI-NIC.ARPA>
ReSent-To: tcp-ip@SRI-NIC.ARPA
ReSent-Message-ID: <12432160081.29.SAPPHO@SRI-NIC.ARPA>

    Barry,

    I don't profess to be an expert and may get flamed but here goes:

              LOGICAL HOSTS ON AN ARPANET STYLE CLASS A NETWORK

    As you know, the third field of an Arpanet/Milnet style Class A IP
    address is called the logical field.  The use of this field is very
    controversial.  For the Milnet at least, the NIC has stated that they
    are not authorized to issue logical addresses.  The reason for the
    restriction will become clear later.  In theory and practice, one can
    use this style of address to place several Class A hosts behind a
    single PSN port.  Figure 1 shows three hosts connected to a
    concentrator, an IP router.  In DDN terms, this device is referred to
    as a transparent gateway.  This transparent gateway is in turn
    connected to a single port of a PSN.

(text omitted here)

    There are several problems with this arrangement.  First and
    foremost, RFC 1005 (May 1987) contains a suggestions for rearranging
    the 32 bit IP address.  This suggestion, if adopted, would render the
    transparent gateway router useless.  This is why the Milnet manager
    is discouraging the use of this addressing scheme.  Users are not
    restricted from using this field, they are only restricted from being
*   published in the NIC's host table.  (for a good horor story, ask Mary
*   Stahl at the NIC about a site she worked at where this type of
*   address caused many problems.) Without being published in the NIC's
    host table, it is difficult to receive electronic mail without the IP
    address as the distant end will have no way of knowing which PSN and
    port the host is on.  This is not a problem if the DOMAIN server
    system is employed.  The domain server system allows hosts to receive
    mail without being on the NIC's host table (see RFC 1032 through RFC
    1035).  However there are many domains (like mine) which do not
    employ this wonderful and intelligent design.

(remainder of msg text omitted)

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


-------
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Thu 13 Oct 88 11:56:36-PDT
From:      John Wright <JOHN@MATHOM.CISCO.COM>
To:        mcvax!hp4nl!hpuamsa!bert@uunet.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SLIP over Telnet...
cisco's terminal servers have SLIP support. Usually a microcomputer
acting as an end-node on the network running some version of PC-IP out
of it's RS232 port connected to one of the RS232 lines of the terminal
server.

John Wright
Customer Engineer
cisco Systems, Inc.
-------
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Oct 88 09:22:06 EDT
From:      Mark Bodenstein <MAB@CORNELLC.CCS.CORNELL.EDU>
To:        CERF@A.ISI.EDU, sandy@TOVE.UMD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: simultaneous connections
The VMNET IBM-RSCS-over-TCP implementation from Princeton takes advantage
of this feature of TCP.  Servers both listen for connections and actively
try to connect to other servers.  Only one connection is desired between
any two servers.  (Very) Occasionally SYNs will be sent simultaneously
from two servers to each other.  TCP makes sure this results in one
connection.

Mark Bodenstein
Cornell University
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 88 05:57:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: simultaneous connections

In systems which operate a distributed, common algorithm which does
not use the master/slave or caller/callee model, the TCP was specifically
designed to allow to processes to reach each other concurrently and
wind up with a single connection. The ISO model tends to be master/slave.

I do not know whether any distributed systems in the Internet take 
advantage of the TCP design feature but at the time of its design,
TCP held symmetry to be a highly valuable characteristic.

Vint Cerf

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Oct 88 11:59:24 edt
From:      stjohns@beast.DDN.MIL (Mike St. Johns)
To:        steinmetz!vdsvax!barnett%vdsvax.steinmetz.ge.com@uunet.uu.net
Cc:        tcp-ip@sri-nic.arpa
Subject:   Broadcast RPC question
This isn't an answer to your question, just a complaint from the
protocol police.

I just checked the records and network "3.x.x.x" has not been
allocated to anyone.  To get your own personal network number, you
MUST contact "Hostmaster@SRI-NIC.ARPA".  Making up your own network
number and using it is NOT a good idea.

Mike
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Thu 13 Oct 88 15:26:59-PDT
From:      William Westfield <BILLW@MATHOM.CISCO.COM>
To:        mcvax!hp4nl!hpuamsa!bert@uunet.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SLIP over Telnet...
The cisco Systems terminal servers also suppport SLIP directly
on the terminal server...

William Westfield
cisco Engineering
-------
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Oct 88 12:40:48 EDT
From:      bzs%bu-cs.BU.EDU@bu-it.bu.edu
To:        mcvax!hp4nl!hpuamsa!bert@uunet.uu.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   SLIP over Telnet...

>Most terminal servers run Telnet (MI NTS 100, Bridge CS100, UB NIU 180,
>Spider etc.)

Encore's ANNEX supports SLIP over a serial line (up to 38.4Kb). It was
demoed at the Show-and-Telnet last week with an X11 terminal.

	-Barry Shein, ||Encore||
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Oct 88 12:47:44 EDT
From:      Mills@UDEL.EDU
To:        CERF@a.isi.edu
Cc:        sandy@tove.umd.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  simultaneous connections
Vint,

The only scenario I know in the Internet archeology is the relic
Multimedia Message Protocol (MPM), in which the message agents used
the same TCP port number for both the source and destination ports.
Thus, in the not unlikely case that two agents attempted to open
a connection at the same time to each other, only one connection
would ever occur. This actually was quite handy in that it conserved
resources and avoided some awkward race conditions in the spoolers, etc.
However, I do not know of an application that simply would not work
if two connections resulted, rather than one, unless that application
required message ordering to be preserved, and even in that case I
would be a little uncomfortable if the key to preserving order was
to require only one connection, rather than two.

Dave
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Oct 88 14:00:12 EDT
From:      jose@MCL.UNISYS.COM (Jose Rodriguez)
To:        tcp-ip@sri-nic.arpa
Cc:        jose
Subject:   dynamic IP address assignment...

I think Mr. Michaelson refers to what I was wondering is the big problem
of dynamic IP address assignment: how to get other systems to know what
your new IP address is.

I am wondering if anyone is working in solving the problem of logical
addressing in some generic fashion. We have been working on this
name server whose entries can be modified through the network
in real-time (well almost real time) ...

Jose
jose@kauai.mcl.unisys.com


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 88 14:35:18 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: what is dynamic IP address assignment

In the ham radio tcp/ip world we're facing the need for dynamic address
assignment too.  Since the service is radio-linked, and people often
move, we have no central control over connection into our network.  Nor, 
I suspect, do we really want such.

The solution I've been toying with was to let the regional network
access nodes assign the addresses.  (Access by user stations/hosts to
the network is to be via dedicated network access nodes, similar in
concept to an IMP).  When a user station fires up in an area, he
requests assignment of an IP address (using some variant of RARP, I
suspect), and the local access node simply assigns the next one of its
allocated block of addresses to him.  The address is cached and will
be freed for reuse if no traffic is seen by that node from that station
for some reasonable period - like six months or so.

Since the underlying transport network (ham radio) has unique
identifiers (callsigns), this is a relatively straightforward way to
handle the problem.  I can see variations on the theme: that assignment
ALSO updates the distributed nameserver database; that there exists a
way to flush a station's entries from the address cache; etc.

With over 1500 hosts registered in over 20 countries so far, and more every 
day, we've got to find some way to automate the address assignment process.

	Brian Kantor	WB6CYT	UC San Diego   brian@ucsd.edu

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 88 16:06:39 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP

In article <187@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>OK, my next question is "what is the purpose of NetBIOS over TCP" ?
>I see two answers:  (1) To take the existing horde of NetBIOS
>applications and run them on other systems;  (2) To provide another
>communication interface for a programmer.
>
>The problem with (1) is that I'd guess 99.9% of all existing NetBIOS
>applications are written *specifically* for the IBM PC and that a
>vast majority of them contain a lot of assembler code.

Very correct. Some vendors have talked about "porting NetBIOS" to UNIX
or other such systems. What they mean is bringing up the RFC 1001/1002
protocols under these systems, and some kind of who knows what
programming interface that probably can't have anything to do with the
standard NetBIOS interface unless you're running on an 80x86 system.

There's a worse problem, even in the PC domain. Many NetBIOS
applications, especially IBM-written ones, make use of undocumented
NetBIOS features, or timing or other bizarre details of the oldest
NetBIOS implementations, and it's pretty difficult to get these things
running correctly over NetBIOSes that are substantially different from
the IBM ones.

>The problem with (2) is who needs it ?  Wanting to preserve the

I don't know.

>It seems I'm missing something in the reasoning behind wanting
>NetBIOS over TCP, but given that vendors exist that sell this as a
>product there must be a need for it.  Can someone shed some light on
>just what people are doing with it ?  Thanks.

I think the whole purpose of NetBIOS over TCP is a political/marketing
one. A couple of years ago a lot of people thought that NetBIOS was
going to be THE way to go, THE way to talk to networks, because IBM
had blessed it. Right. So you saw NetBIOS over Netware, over 3+, over
ISO, over DECNet (I think), and then over TCP, by Excelan and
Ungermann-Bass. At the Air Force's behest (because of ULANA and all),
RFC 1001 and 1002 were written after much beating up of all parties
involved so that different vendors' NetBIOS over TCP's could actually
interoperate.

Why do the vendors care? As near as I can tell, it's so that they can
say they're IBM-compatible (never mind that a TCP NetBIOS wouldn't
talk to a NetBIOS over IBM protocols), and so because their customers
really told them they wanted NetBIOS.

When I was at FTP Software, I saw that a lot of the market place
didn't have the foggiest idea what NetBIOS was. "It lets you share
printers!" they cried. "We can use fileservers!" they said. "It does
record locking."

Right.

So now probably thousands of users have their NetBIOSes, like they
asked for. I think some of them run Microsoft Networks or the PC LAN
program in some version or another over it (seems a bit gratuitous on
Novell Netware or 3COM 3+), and there are a few database products that
let you query a central database through protocols that run over
NetBIOS. Other than that, I don't have the faintest idea what people
are using it for.
-- 
			- john romkey
UUCP: romkey@asylum.uucp		ARPA: romkey@xx.lcs.mit.edu
 ...!ames!acornrc!asylum!romkey		Telephone: (415) 594-9268

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 88 22:32:42 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   TCP over FDDI encapsulation

Is everyone going to use RFC 1042's recipe for 802.2 LLC encapsulation
of TCP/IP, but over FDDI instead of ether?

Is anyone thinking of encapsulating IP in other than 802.2?  Perhaps using
one of the 'implementor defined' frames?

Please let me know if this has already have been thrashed out, and
where I might discover the results.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Oct 1988 06:33 EST
From:      Suresh Konda <KONDA@VM.CC.PURDUE.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   SFTP implementations
I am interested in using SFTP at our site here.  In particular, I would
be very grateful for pointers, warnings, server or client sources etc.

More generally, we are interested in a "simple" way to transfer a well
specified set of files to/from the server where simplicity refers to
the user interface, RAM requirements, and communications overhead.

The set up we have is messy but here it is:  an RT/PC running BSD4.3
as the server (with  both token-ring and ethernet cards),
Macs and PC's (with LocalTalk cards) connected to several
KFPS-4's,  HP9000/3xx's on ethernet, and IBM 6152's (these are PS/2's with
a RISC card running DOS on the 80286 side and BSD 4.3 on the RISC side)
on token ring.

Any suggestions will be greatly appreciated in taming this beast.
Thanks very much.

Suresh Konda
konda@purccvm.cc.purdue.edu
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Oct 88 08:21:16 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        munnari!ditmela!george@uunet.uu.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: what is dynamic IP address assignment

> some peoples suggestions about what dynamic IP address assignment offer 
> seem (to me at least) to float functionality which requires propagation
> of the new address "binding" out into the world. -If I wanted to take
> a portable IP-using box around the country, and somehow get an IP address
> at <new local point of attachment> and somehow propagate that back to
> <my mail store host> and thus read my mail, I'd be doing things like that
> wouldn't I?

Not necessarily.  Some proposals would do that, others would not.

For example, if I give you an IP address on the network of your new
point of attachment, no address information needs to be propogated
past your gateway (your gateway will need an ARP entry for you).
Outside your network, the Internet will be routing to your network,
not your host #, and so the new host address does not have to be propogated
for information to be exchanged.

The nastier problems are:

    (1) Do you want to update your domain system RR?

	My assumption is that the answer to this question is "no" because
	you won't be using the address long enough (a few days or so at
	most) to make the effort worth it.  That's a nice assumption
	to make because, currently, the DNS doesn't allow such dynamic
	updates.

    (2) How do you authenicate yourself for, say, running POP or other
	sensitive protocols.  (I say sensitive because you don't want
	someone else to be able to run POP and read your mailbox).

By the way, my earlier airplane example led someone to believe that as 
I was cross the country, my host was casually changing networks as
we passed over them.  My assumption is, rather, that the airplane itself
has an Ethernet installed in it and thus you simply join the network.
What changes in the "best" gateway to your network.

Craig
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Oct 88 08:51:05 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Jose Rodriguez <jose@mcl.unisys.com>
Cc:        tcp-ip@sri-nic.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: dynamic IP address assignment...
     ... how to get other systems to know what your new IP address is.

If I am a roving PC, then I might only need the address as long as the
connection session I am running.  I am only opening Telnet, FTP, SMTP, or
MAIL-DRAIN connections with various other hosts, and it should be sufficient
for me to have a unique address and a local name (like [10.1.99.5] =
host99.roving-service.net).

If I am less transient, as visiting some place for a day/week/semester, I
could get the address locally, and then register the address with my home
domain name servers.  Then anyone who does the normal domain lookup for my
host mike-brescia.bbn.com will get the ip address you assigned me when I set
up on the guest desk, and my mail starts getting delivered again.  A further
protocol development here is needed, so that I can do the address installation
automatically rather than having to send mail to the DNS administration people
and incur another delay, as well as have some way to remove the address
mapping again when the address is recycled.


     ... the problem of logical addressing in some generic fashion.

I haven't seen any comments yet on the possibility of IP multicast being used
for groups which have only one member.  This does sound like a logical
address, and the routing is set up by the host announcing to the local
gateway.  If, as Mark Lottor has found, there are more than 50,000 hosts,
would IP multicast be able to handle that many?  

Mike
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Oct 88 09:30:19 PDT
From:      postel@venera.isi.edu
To:        mfci!hsi!stevens@uunet.uu.net
Cc:        postel@venera.isi.edu, tcp-ip@sri-nic.arpa
Subject:   Re: NetBIOS over TCP/UDP
Richard Stevens:

The main point of NETBIOS over TCP/UDP is to be able to have applications over
NETBIOS work together beyond the limits of a single local network. Putting
NETBIOS over TCP/UDP allows applications over NETBIOS to communicate with
each other anywhere in the Internet of over 500 networks and 25,000 computers
spread from Hawaii to Germany.

--jon.
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Oct 88 09:43:22 -0400
From:      Scott Brim <swb@dainichi.tn.cornell.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: SLIP over Telnet...

  >>Would it be possible to run SLIP trough a so called terminal server ?
  >
  >A more reasonable use of a terminal server would be for it to support
  >SLIP directly.  Cisco does that.  It's fairly easy, so I would think
  >others would as well.  

Encore does it too, for example.
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Oct 88 14:35:44 PDT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        tcp-ip@sri-nic
Subject:   Lanalyzers and Laptops
Afternoon all...
		I know there were several messages awhile ago about putting
a Lanalyzer into a Toshiba 3200 Laptop PC.  Unfortunately, I don't remember
the final word on the subject. I happen to have an EXOS 225 card that I
want to continue using, and I've finally managed to convince management
that a laptop is a necessity(not to mention a real fun toy |*). The question
is ..... Will it work? I know that the Toshiba requires the board
to live above E0000 but has anybody got one running?
		THanks in advance,
				  Chris VandenBerg
				  ACC
				  (chris@acc-sb-unix.arpa)
				  805-963-9431 x 296
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 88 12:30:00 GMT
From:      cball@ishmael
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC question


>/* Written 12:51 pm  Oct 12, 1988 by barnett@vdsvax.steinmetz.ge.com in ishmael:comp.protocols.tcp-ip */
>/* ---------- "Broadcast RPC question" ---------- */
>We have a problem on our network with diskless Suns running SunOS 4.0.
>At times they are unable to boot, due to some condition on our
>network.

What are the ifconfig command arguments in the boot file(/etc/rc.boot
in SunOS 3.5)?
We had an intermitant problem with diskless stations using any SunOS that
supports subnets (3.4 or later) on a net with Vaxes running Wollengong TCP.
The fix was to explicitly set the netmask in the ifconfig command.  Try
something like:

ifconfig le0 $hostname netmask 255.255.252 broadcast 3.1.4.0 -trailers up

This workaround was suggested in a discussion about 18-24 months ago.

Charles Ball
cball@Inmet.com
Intermetrics, Inc.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 88 14:10:11 GMT
From:      larry@tapa.UUCP (Larry Pajakowski)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP

Well we do run Netbios over UDP and are very pleased with it.  Here are
some reasons.

1.  Our primary reason is that we dos software developement for both DOS and
Unix/Xenix.  Our server is a Compaq-386/20 running Xenix.

2.  We have 1 set of source on the server for both Xenix and DOS in 1 place.

3.  We use SCCS on the Xenix side for all source.

4.  Our implimentation comes with ftp and telnet which allows us to test the
Xenix version from a DOS box.

5.  Dates and time stamps are preserved between the Xenix and Dos files.

6.  We had our choice of servers: Xenix, Vaxen under VMS, NCR towers etc.

7.  Dos developers can share the LASER printer on the Xenix system.

8.  Dos developers use uucp heavily to move files between remote sites.

9.  Other non technical personel are also on the LAN makeing for moving 
documents and mail easy.

All in all we are very pleased with the development environment.


Larry
larry@tapa

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 88 22:27:00 PST
From:      <lars@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        "romkey" <romkey@asylum.uucp>, "stevens" <stevens@hsi.uucp>, "lars" <lars@salt>
Subject:   Why NETBIOS over TCP/IP

In article <187@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>It  I'm missing something in the reasoning behind wanting
>NetBIOS over TCP, but given that vendors exist that sell this as a
>product there must be a need for it.  Can someone shed some light on
>just what people are doing with it ?  Thanks.

Here are my two cents' worth:

A network product is not useful unless it serves a function to the user.
You can have a wonderful network interface card, but if you sell a
blank card, you have not provided a function to the user.

The functionality that users care about are things like
- shared print (s)pools
- file sharing
- mail systems
- conferencing

In order to provide this kind of functions, you need massive amounts of
software. With NETBIOS, IBM provided a family of upper level protocols
with well-defined hooks to the media interfaces. This made it possible
for somebody who wanted to make smart cards to get the upper stack for
free. It might not be the worlds best upper stack, but it was almost free
and came complete with user manuals.

Next, somebody observed that if you stick a standard internet protocol
in the lower stack, such as IP, you could gain additional functionality
such as wide area bridging between the PC-LANs, again with a minimum
of efforts.

Finally, somebody decides to turn a unix machine into a file server
by faking out the PC behind the pseudo-gateway.

At this point, someone who would rather see NFS used for this purpose
tends to complain, because the original upper stack may use undocumented
protocol features. 

I agree, it is nice to have a perfect protocol stack. And if you are a
small vendor, it is infuriating to have to emulate all the bugs in
somebody else's proprietary undocumented protocol. It is much nicer to
have a committee-designed but well-documented monster protocol,
so you at least can point fingers and say the bug is not on my end.
But it is the existence of this very proprietary top stack that has
allowed several vendors to get into business making NETBIOS-bottoms
that run on Ethernet, Starlan, X.25 etc.

/ Lars Poulsen				(Speaking strictly as an individual)
  Advanced Computer Communications	(Affiliation for Identification only)

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 88 16:31:15 GMT
From:      stuart@speedy.cs.wisc.edu (Stuart Friedberg)
To:        comp.protocols.tcp-ip
Subject:   Re: simultaneous connections

In article <[A.ISI.EDU]13-Oct-88.01:57:40.CERF> CERF@A.ISI.EDU writes:
>I do not know whether any distributed systems in the Internet take 
>advantage of the TCP design feature but at the time of its design,
>TCP held symmetry to be a highly valuable characteristic.
>
>Vint Cerf

I am using the "active-active" connection protocol as the starting
point for (re)configuring distributed programs under remote control.
A "third-party" makes the decisions about who talks to whom, then
instructs the workers to establish a connection.

Master/slave introduces a completely unnecessary asymmetry into a peer
relationship between worker programs.  The "master" is the third-party
manager, which doesn't have anything to do with the TCP connection
itself, at all.  So, we are using the symmetric variant, and I am
quite thankful that the TCP design group (committee? mob? clique?)
provided it.

Stu Friedberg  stuart@cs.wisc.edu

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 88 22:57:34 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: simultaneous connections

>I do not know whether any distributed systems in the Internet take 
>advantage of the TCP design feature but at the time of its design,
>TCP held symmetry to be a highly valuable characteristic.
>
>Vint Cerf

Doesn't the FTP "Three Party Model" depend on symetric, peer-peer
connections? There are several FTP's out there that support Three Party, not
to mention Braden & DeSchon's work on BFTP.

Ross Patterson
Center for Computer and Information Services
Rutgers University

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Oct 88 23:13:44 +0100
From:      Yuko Murayama (+44-1-387-7050 ext.3695) <murayama@Cs.Ucl.AC.UK>
To:        George michaelson <munnari!ditmela!george@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: what is dynamic IP address assignment


George,

I might be able to give you my view (not answer) for your first problem.

>         (1)     what is the scope and validity of a temporary assignment
>                 within the INTERnet at large?
>

> some peoples suggestions about what dynamic IP address assignment offer
> seem (to me at least) to float functionality which requires propagation
> of the new address "binding" out into the world. -If I wanted to take
> a portable IP-using box around the country, and somehow get an IP address
> at <new local point of attachment> and somehow propagate that back to
> <my mail store host> and thus read my mail, I'd be doing things like that
> wouldn't I?

I would argue if we really need propagation of the new address binding
out to the world.  It seems to depend on whether the object of
concern has potential to be a "server" or not.

For instance, if you attached your PC to the new location and
did telnet to <your mail store host> to read mail, your PC
would be the initiator of the telnet connection.
The mail store host will know your PC's new address naturally
by the source address field of the incoming packets.
Your PC could be a server, but in this particular example,
it is not, it's a client.

If the object is supposed to act as a server as well as a client,
then the new address should be known to the group of hosts
which would need to initiate the connection to get this service.
It is this case where we need some propagation scheme or
possibly registration scheme in the public domain.

Yuko
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 88 01:22:02 GMT
From:      microsoft!waynec@beaver.cs.washington.edu  (Wayne Chapeskie)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: NetBIOS over TCP/UDP
[This is a bit long, but I hope it clarifies things a bit.]

In article <187@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>In article <957@asylum.UUCP>, romkey@asylum.UUCP (John Romkey) writes:
>> 
>> Sorry, but that IS Netbios. The programming interface defines the
>> semantics of the network operations and how you call them, and that's
>> it. Netbios is the programming interface, not what's under it.
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>OK, my next question is "what is the purpose of NetBIOS over TCP" ?
>I see two answers:  (1) To take the existing horde of NetBIOS
>applications and run them on other systems;  (2) To provide another
>communication interface for a programmer.

Not exactly.  "Netbios" tends to be a rather slippery term.
There are really two aspects to "Netbios":

1.  An msdos programming interface  (the "NCB", or "Int5c" interface).
    This interface is what was promulgated by IBM in their original
    PCNET product, picked up by Microsoft in MSNET.

2.  A set of networking functionality, which is implied by the
    interface.  This functionality includes a reliable, virtual
    circuit transport facility with the ability to preserve message
    boundaries, an unreliable datagram facility, and a naming
    convention.

    The precise nature of the underlying network transport was not
    defined:  you could put any
    combination of hardware and software transport you wanted there,
    as long as it provided the kind of circuit, datagram, and naming
    facilities implied by the upper level interface.
    Msdos network vendors did exactly that:  each had their own combinations
    of network hardware and protocols (often completely nonstandard).
    Even if they did use standard protocols (ISO, TCP/IP, XNS) down in the
    transport level, they still had to do something on top of them to
    provide the session level naming facilities required by the interface.
    You even have  cases where two vendors have both used
    the same transport level protocols (XNS, TCP/IP), but since they
    use different methods to implement the Netbios naming support, their
    Netbios implementations cannot communicate.

While the NCB interface was rigidly defined, and msdos programmers
have written "Netbios applications" which use it,
the NCB interface itself is strictly an msdos convention, and a pretty
sleazy one at that...  [There have been attempts to provide
exactly such an interface on Unix systems, in order to somehow make it
easier to port msdos Netbios programs to Unix.  I consider such
attempts misguided, and quite inappropriate to a Unix environment].
There is no requirement that the NCB interface be used to "speak
Netbios"; any interface which makes sense to the local
operating system can be used.

As a concrete example:  we have hordes
of Ungermann-Bass boards around here which implement all of Netbios
in slushware.  An msdos machine has a driver which takes "int 5c" NCB
commands and tells the board to do the appropriate thing.
On my Unix machines, I did a unix device driver which knows how to
talk to the board.  I have done versions of the driver which used
a device ioctl interface, and versions which use Sys
5.3 streams/TLI interfaces to talk to the driver.  I have never provided
an NCB interface.  Yet programs on the Unix machine can speak to
programs on the msdos machine, and so are in a sense "Netbios programs".

As you may gather from the earlier discussion, interoperability
among Netbios implementations is essentially non-existent.
Msdos programmers have this interface to write programs
to, but their programs can only talk to each other if the underlying
network transport services which implement the interface are
compatible.   RFC 1001/1002 attempt to ensure that this is the case
if the the underlying transport is TCP/IP.
They specify a protocol which lives on top of TCP/IP, implementing
Netbios name service, datagram delivery, circuit establishment,
and so on.  [A similar effort is also being made for Netbios over ISO TP4.]
The RFC's ensure that vendor A's "Netbios over TCP/IP" will
communicate with vendor B's "Netbios over TCP/IP". 

Since the RFC's do not specify a programming interface to the Netbios
facilities, the interface will be whatever is appropriate for the host
system.  Msdos implementations would no doubt be NCB, Unix
implementations may use the socket interface, TLI, generic cover
routines, or whatever, depending on how the RFC layer is implemented.
The point is to make sure that you know how to talk to the msdos machine.

So, I see two reasons for the "Netbios over TCP/IP" spec:
1.  Guarantee interoperability for those msdos Netbios implementations
which use TCP/IP as their underlying transport.
2.  Provide a mechanism for machines which already talk TCP/IP (your
average Internet host) to communicate with msdos Netbios programs, 
(i.e. msdos programs which do not talk TCP/IP directly).

[My apologies if you knew all this already.  However, this whole
"Netbios" silliness is often misunderstood...].

Wayne Chapeskie
(206)-882-8080			UUCP:  ...{uw-beaver,uunet}!microsoft!waynec
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Oct 88 12:46:39 PDT
From:      braden@venera.isi.edu
To:        brian@ucsd.edu, jon@cs.ucl.ac.uk
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: what is dynamic IP address assignment
	
	Have you looked at the way cellnet phones work in the UK - i can dial
	someone in a fast moving car, from a fast moving car, using the same

You will note that there are no slow-moving cars in the UK.  If you have
tried to cross a busy London street without being killed, you will 
appreciate this.

   Bob Braden	
	
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Oct 88 12:22:23 edt
From:      stjohns@beast.DDN.MIL (Mike St. Johns)
To:        postel@venera.isi.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Net 3 assignment
Jon and co:

The source I checked for the network number assignments was one I
considered authoritative - the NIC WHOIS database.  It does not list
net 3 as being assigned to anyone.  Jon has told me this number is
assigned legally so I withdraw my complaints.

I'd like to ask people who own network numbers to check the
information contained in the NIC database and to update it if its out
of date.  You can connect to the NIC and do a "WHOIS NET 192.33.3.0"
substituting your network number for mine to check your information
(those 4.xBSD style hosts can use the host "whois" command to the same
effect)    Send updates for your information to
"HOSTMASTER@SRI-NIC.ARPA"  

Thanks, Mike
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Oct 88 19:01:34 PDT
From:      hjs@lindy.Stanford.EDU (Harry Saal)
To:        tcp-ip-request@sri-nic.ARPA
Subject:   Re: Lanalyzers and Laptops

The EXOS 225 board will not work in a Toshiba 3200 because the
bus speed is 12 Mhz. It will also not work in an IBM AT running
with an 8 Mhz bus, and must run in a 6 Mhz, bus. This is documented
in Excelan's reference manuals for the Lanalyzer.
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Oct 88 19:05:57 PDT
From:      hjs@lindy.Stanford.EDU (Harry Saal)
To:        barnett@vdsvax.steinmetz.ge.com, tcp-ip-request@sri-nic.ARPA
Subject:   Re: Broadcast RPC question
Bruce-

Here is a dump (slightly edited to include hex parms) from the Sniffer
of the two frames you included in your message of 12 Oct 88.  The
diskless SUN is addressing port 111, which is (correctly) SUN's RPC
port.  It is calling the PMAP (Port Mapping) program, asking it to 
make a call to Program 100026, procedure 1 with 5 words of arguments.

We don't know what this particular program is, since we haven't seen
it in SUN's documentation.

The fact that many stations receiving this IP packet don't recognize
port 111 is not a surprise, hence the ICMP replies.

You didn't describe in what fashion the SUN's 'are unable to boot'.
Surely one problem is that they will receive many many ICMP replies,
which can cause their frontend's to have to drop packets.

- - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - - - - -


DLC:  ----- DLC Header -----
DLC:  
DLC:  Frame 1 arrived at  00:00:00.0000 ; frame size is 142 (008E hex) bytes.
DLC:  Destination: BROADCAST FFFFFFFFFFFF, Broadcast
DLC:  Source     : Station Sun   019C27
DLC:  Ethertype = 0800 (IP)
DLC:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4, header length = 20 bytes
IP:   Type of service = 00
IP:         000. .... = routine
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 128 bytes
IP:   Identification = 0
IP:   Flags = 0X
IP:   .0.. .... = may fragment
IP:   ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 255
IP:   Protocol = 17 (UDP)
IP:   Header checksum = B049 (correct)
IP:   Source address = [3.1.5.35]
IP:   Destination address = [3.0.0.0]
IP:   No options
IP:   
UDP:  ----- UDP Header -----
UDP:  
UDP:  Source port = 1023
UDP:  Destination port = 111 (Sun RPC)
UDP:  Length = 108
UDP:  No checksum
UDP:  
RPC:  ----- SUN RPC header -----
RPC:  
RPC:  Transaction id = 527667699
RPC:  Type = 0 (Call)
RPC:  RPC version = 2
RPC:  Program = 100000 (Port mapper), version = 2
RPC:  Procedure = 5 (Indirect call routine)
RPC:  Credentials: authorization flavor = 1 (Unix)
RPC:  [Credentials: 24 byte(s) of authorization data]
RPC:  Verification: authorization flavor = 0 (Null)
RPC:  [Verification: 0 byte(s) of authorization data]
RPC:  
RPC:  [Normal end of "SUN RPC header".]
RPC:  
PMAP: ----- SUN Port Map -----
PMAP: 
PMAP: Proc = 5 (Indirect call routine)
PMAP: Program = 100026, version = 1, proc = 1
PMAP: [20 byte(s) of argument data]
HEX:  00000014 00000001 00000003 00000001 00000005 00000023
PMAP: 
PMAP: [Normal end of "SUN Port Map".]
PMAP: 


- - - - - - - - - - - - - - - - Frame 2 - - - - - - - - - - - - - - - - -


DLC:  ----- DLC Header -----
DLC:  
DLC:  Frame 2 arrived at  00:00:00.0000 ; frame size is 70 (0046 hex) bytes.
DLC:  Destination: Station Sun   019C27
DLC:  Source     : Station DECnet006010
DLC:  Ethertype = 0800 (IP)
DLC:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4, header length = 20 bytes
IP:   Type of service = 00
IP:         000. .... = routine
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 56 bytes
IP:   Identification = 732
IP:   Flags = 0X
IP:   .0.. .... = may fragment
IP:   ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 255
IP:   Protocol = 1 (ICMP)
IP:   Header checksum = ADC5 (correct)
IP:   Source address = [3.0.0.0]
IP:   Destination address = [3.1.5.35]
IP:   No options
IP:   
ICMP:  ----- ICMP header -----
ICMP:  
ICMP:  Type = 3 (Destination unreachable)
ICMP:  Code = 3 (Port unreachable)
ICMP:  Checksum = A86C (correct)
ICMP:  IP header of originating message (description follows)
ICMP:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4, header length = 20 bytes
IP:   Type of service = 00
IP:         000. .... = routine
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 128 bytes
IP:   Identification = 0
IP:   Flags = 0X
IP:   .0.. .... = may fragment
IP:   ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 255
IP:   Protocol = 17 (UDP)
IP:   Header checksum = 0000, should be B049
IP:   Source address = [3.1.5.35]
IP:   Destination address = [3.0.0.0]
IP:   No options
ICMP:  
ICMP:  [First 8 byte(s) of data of originating message]
ICMP:  
ICMP:  [Normal end of "ICMP header".]
ICMP:  

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 88 14:41:56 GMT
From:      nasa@ms.uky.edu (Eric T. Freeman)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   EXOS EX__XXCTL function



If anyone has been able to use the EXOS EX__XXCTL function to 
retrieve the IP address of the remote telnet client could you please
help me?  I've been trying to use the function but haven't been able
to get it to work.

			Thanks,
			
			Eric Freeman

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Eric Freeman					"Drive you when you're down - 
eric@dftsrv.gsfc.nasa.gov			 dreams transport the ones
freeman@dftnic.gsfc.nasa.gov		         who need to get out of town"	
nasa@g.ms.uky.edu					-Peart

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Oct 88 16:54:51 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        Brian Kantor <brian@ucsd.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: what is dynamic IP address assignment



 >In the ham radio tcp/ip world we're facing the need for dynamic address
 >assignment too.  Since the service is radio-linked, and people often
 >move, we have no central control over connection into our network.  Nor, 
 >I suspect, do we really want such.

Have you looked at the way cellnet phones work in the UK - i can dial
someone in a fast moving car, from a fast moving car, using the same
telephone number allways, and both call endpoints are being
dynamically re-assigned to new exchanges as we move thru cells -ok its
circuit oriented, so a bit easier to do this with, plus its broadband
and broadcast, so some mechanisms are feasible that dont work in an
internet, but its radio - plus its a great deal more than 1500 live
users...


 jon

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Oct 88 17:24:53 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Network Management Tools

Some time ago (june) i mailed this list with a request for information
on network management tools for TCP/IP networks. After a second
attempt, I had a total of 8 replies, most of which were supportative
in seeking the information.

Thanks v. much to Bob Braden for showing me the fun of NNStat
Doug Elias for talking about netspy and an astute observation that the
most common 'common management tool' is telnet (whats that, i use
rlogin), by someone whose message i'm afraid i've lost.


Anyhow, i wrote a short unbalanced structure for a document to hang 
all the glorious management tool technology round, and append the structure, 
which unfortunately has gaps instead of teeth, and is 99.83% overtaken by
the hosts requirement and gateway requirement RFCs, and is simple
minded as well as out of date

The appendix on proprietary tools and performance have been left of as
either copyright, or irrelevant - i'm not sure which

never mind

jon




			How we failed to go about
	       Managing	TCP/IP Networks, Internal Note 2284

			       J. Crowcroft

				M. Riddoch

		      Department of Computer Science
	University College London, Gower Street, London	WC1E 6BT.

				 ABSTRACT



	     This is an	overview of the	 mechanisms  used  to
	     manage TCP/IP networks. Most of these mechanisms
	     are part of the Berkeley Unix (4.2	or  4.3	 BSD)
	     release.  Some are	specific to Sun	Microsystem's
	     own version of BSD. Most are available  in	 some
	     form  or  other  on  any  TCP/IP  host.  A	large
	     proportion	are ethernet specific.

       1.  Introduction

       This note is an attempt to gather together a description	 of
       as  many	 of  the  tools	 for  TCP/IP  Network management as
       possible. It is necessarily  incomplete,	 and  also  out	 of
       date.

       The rest	of the note is divided into five sections:

	 1.  Configuration

	     Configuration  of	hosts,	Bridges	 and  gateways	 is
	     discussed,	  covering  name  and  address	allocation,
	     protocol parameter	choice and routing.

	 2.  Statistics	and Faults

	     A number of ways of gathering statistics  (intrusively
	     or	 by  passive observation of hosts and networks)	are
	     listed. A number  of  tools  for  traffic	generation,
	     performance   monitoring	and   fault  isolation	are
	     described.

	 3.  Security and Access Control

	     There is a	lot of concern about  security	(especially
	     of	Unix systems, and NFS'd	Unix systems). This section
	     lists some	of the ways in which access control is	set
	     up	 for  Unix  systems,  and some of the ways in which
	     security  breaches	 may  be  detected,   tracked	and
	     controlled.

	 4.  Electronic	Mail












				  - 2 -



	     Electronic	mail is	very complex to	setup and manage in
	     the  heterogeneous	 environment  we have and expect to
	     continue at  UCL.	A  reasonable  description  of	the
	     system  within  CS	can be found elsewhere (Hassell	and
	     Kille - Meta guide	to  CS	mail...and  other  internal
	     notes).  However,	a few very brief notes are included
	     here.

       An appendix lists some of the tools  available  for  all	 of
       this.  It  is  important	 to  note that Unix is not the only
       system  that  runs  TCP/IP,   but   that	  most	 reasonable
       implementations	(many  TCP/IP  for VMS)	derive closely from
       BSD Unix, and that management in	those systems  is  similar.
       Even  a	number	of  the	 PC  based  TCP/IP  products have a
       reasonable subset of the	same functionality.

       Another appendix	lists some simple  performance	figures	 of
       various hosts at	CS, via	various	routes.

       It is also worth	noting that there are large  quantities	 of
       public  domain  software	available from the US, and that	UCL
       has good	access to such software	(and expertise)	because	 of
       our history of working with US organisations.


       2.  Configuration

       2.1  Hosts

       When a new host is installed the	following  list	 of  things
       need configuring:

	  o Addresses

	    Internet addresses come in 3 forms,	class A, B and C.

	    A has the 1st byte network,	and the	last 3 subnet +	host.
	    B has the 1st 2 bytes network, and the last	2 subnet + host.
	    C has the 1st 3 bytes network, and the last	1 subnet + host.

	    They are distinguished by the first	 bits  (or  easier,
	    0-127  is  A,  128-191  is	B,  and	 192  to 254 is	C).
	    Dividing the rest of the address into subnet  and  host
	    is	based on a subnet mask,	which is chosen	as 0 to	n-1
	    bits of the	host part of an	internet address.

	    IP networks, and  subnets  can  co-exist  on  the  same
	    hardware (e.g. ethernet). The only current restrictions
	    are	that not all machines understand subnets, and  that
	    very  few machines can use more than one IP	address	per
	    physical network interface,	so using different networks











				  - 3 -



	    or	subnets	 may partition hosts on	a network, although
	    the	more intelligent  hosts	 could	be  used  to  route
	    between  such  logical  partitions if really necessary.
	    Subnet masks are configuered using setmask	on  4.2/4.3
	    systems.

	    The	hosts internet address must  be	 assigned.  If	the
	    local  network  already  has  a  network  number  (e.g.
	    128.16.x.y,	or 128.41.p.q),	then only x and	y  have	 to
	    be assigned. If the	network	is subnetted, then only	the
	    last part need be assigned.

	    If there is	 no  network  or  subnet  assigned  yet,  a
	    network  number  must  be applied for from SRI. This is
	    not	necessary for  stand-alone  networks,  but  UCL	 is
	    connected  to  other IP networks. Currently, CS holds 3
	    class B numbers and	on A. We cannot	use the	A,  or	one
	    of	the  B's  (128.41) as they are already allocated to
	    UK-US network service and X.25 PDNs; this  leaves  some
	    of 128.16 address space free, and all of 128.40.

	  o Local net addresses	(below internetwork + link layer).

	    These are almost always set	in  firmware  or  hardware.
	    Some  systems allow	setting	of ethernet addresses. This
	    is extremely dangerous, and	care must be taken  not	 to
	    allocate  duplicates.   Usually, it	is very	OS specific
	    how	one does set these addresses, though  unix  systems
	    have a standard interface configuration program.

	  o Address Mapping.

	    When a new host appears on a local network,	other hosts
	    may	  access   it.	Most  standard	applications  (e.g.
	    FTP/Telnet/SMTP) use well known ports for the transport
	    address,  and  the	internet  address  for network.	The
	    mapping from internet to local net is usually  done	 by
	    ARP	 (see  arpd,  rarpd,  arp  and arpdump), which is a
	    fully distributed automatic	way of locating	hosts,	and
	    requires no	manual intervention.

	    Hosts   with   no	stable	 storage   (PCs,   diskless
	    workstations)  usually  use	Reverse	ARP to get their IP
	    addresses, which  simply  requires	one  or	 more  rarp
	    server  to have the	local net to IP	mapping	for the	set
	    of diskless	machines.

	  o Name management

	    For	humans,	its nice to have names.	For BSD	versions of
	    telnet/ftp,	  which	 are  rlogin/rcp  and  also  remote











				  - 4 -



	    execution (rsh), names are usually used.  Mail  systems
	    use	 names	too.  Names  are  usually  arbitrary  (e.g.
	    pink/parker/opal), although	commonly  managers  try	 to
	    use	 meaningful  names  (vax1/vax2/pyr1),  to  help	the
	    user.

	    The	simplest name management is done via a file of name
	    to	address	 mappings  called  hosts.txt.  Unix  has  a
	    version  of	  this	 for   BSD   applications,   called
	    /etc/hosts.	 This  is  usually managed from	one machine
	    and	distributed to all the others  (by  rdist,  rcp	 or
	    whatever).

	    A number of	newer applications may use Domain Names. CS
	    use	 these indirectly for electronic mail. Domain names
	    are	managed	by a distributed directory service (in	BSD
	    this is the	BIND program). CS build	the /etc/hosts file
	    from the BIND  boot	 files,	 and  distribute  this	for
	    consistency.

	    Sun	and some other systems use Yellow Pages	for similar
	    functionality.  This  is similar to	BIND, although more
	    general.  Essentially, one or more yellow page  servers
	    (and  two  or  more	BIND servers) hold the name/address
	    mappings in	a file or in memory.  Rlogin  or  whatever,
	    when given a name, uses some resolver code to query	the
	    appropriate	name server which returns the address.

	    Yellow  pages  is	also   used   for   password   file
	    distribution, and a	number of related functions.

	    So if some kind of nameserver is being used, then  each
	    new	 host  has  to	be configured with the address (not
	    name!) of one or more nameservers.

	  o Routes.

	    If one is using more than one IP network (and  in  some
	    cases    sub-netting),    there    will    be   routers
	    interconnecting the	networks  or  subnets.	[Note.	Mac
	    level  bridges  are	 competely  transparent	 to TCP/IP,
	    except  for	 some  performance  considerations  -	see
	    below].

	    Standalone routers (e.g. Proteon,  Cisco,  Bridge  Inc,
	    BBN	etc) are one way of doing this interconnection.	BSD
	    Unix machines can also route,  if  they  have  multiple
	    network interfaces.

	    IP	routing	  is   fairly	straightforward.   If	the
	    destination	of a packet is for a different network than











				  - 5 -



	    the	source host is on, it can be sent to  a	 first	hop
	    gateway.  This  may	 be  a	default	configured gateway,
	    which also has to be configured  into  the	host.  Many
	    systems  allow the host to be configured with a routing
	    table of destination network,  and	first  hop  gateway
	    pairs.  Some  more modern systems will exchange routing
	    tables with	each other (BSD	routed,	or RIP or EGP or  a
	    number  of	other  protocols),  so configuration can be
	    simply the addition	of a single routed server to a	new
	    hosts tables, and the rest follows automatically.

	    Machines that actually forward packets (gateways/subnet
	    routers and	the like) are similar. They need to know an
	    IP address for each	interface, and	the  address  of  a
	    neighbour  (if there are multiple hop interconnections)
	    on each net	they are on.

	  o NFS	configuration is fairly	straightforward.  Unix	and
	    other  systems  have  some	notion of filesystems. Unix
	    servers list a set of file systems that  other  systems
	    may	 access	 (via a	file /etc/exports), and	clients	are
	    configured by adding those filesystems to the  standard
	    file  system table (/etc/fstab).  This simply lists	the
	    file systems to be mounted,	where they come	from  (e.g.
	    local disk/partitions, or remote machines).	It also	can
	    control whether the	filestores are readable,  writeable
	    or	read/write.  In	 CS,  we  made	a decision that	all
	    sensible  filesystems  should  be  visible	 from	all
	    machines,  so  the	file tables can	be generated in	one
	    place and distributed around the machines via a utility
	    like rdist.

	  o Broadcasting

	    IP contains	the notion of broadcasting,  which  can	 be
	    useful,  but  can  also  be	extremely hazardous. If	the
	    host (and or subnet)  part of an address is	set  to	 be
	    all	 1s  or	 all  0s,  the	IP  packet  is deemed to be
	    destined for all hosts on this network.  Unfortunately,
	    the	 standard  changed  between  0s	 and  1s,  and many
	    implementations only support one  or  the  other.  Also
	    many  implementations actually break (causing a machine
	    to crash, or flood the network with	ICMP error messages
	    to	the  broadcast	address	 -  broadcast  storm). Some
	    Berkeley applications  (rwho,  ruptime)  use  broadcast
	    regularly  to  announce  machine  and user information.
	    These tend to synchronise between all machines, causing
	    a great deal of collisions on an Ethernet for instance.
	    More  acceptable  systems  use  demand  based  programs
	    (rusers/rup) to query all machines only when asked by a
	    user.











				  - 6 -



	    It is usually configurable whether broadcast  uses	all
	    1s,	 all  0s,  and whether a machine uses any broadcast
	    based applications.	 Care must be taken.

	  o Protocol Parameters.

	    Most TCP and IPs are adaptive, and so  tune	 themselves
	    without   human   intervention.  The  only	exceptional
	    parameters are the TCP MSS (maximum	Segement Size)	and
	    the	 IP  MTU  (maximum trasfer Unit	or Maximum fragment
	    size). Some	systems	allow  tuning  of  these.  Usually,
	    systems use	2 values only, automatically. These are	the
	    local net specific size (e.g. 1500 bytes for ethernet),
	    and	 576  bytes  for remote	network	traffic. Any router
	    that does not  support  at	least  576  bytes  is  non-
	    standard and should	never be bought.

	    Sun's Network  File	 System	 (NFS)	is  a  little  more
	    complex.  The underlying protocol between NFS and IP is
	    rather simplistic, being  unreliable  transaction.	Its
	    defaults  (8k  byte	 messages,  a simple retransmission
	    timeout and	counter)  do  not  work	 well  between	all
	    machines  and over all network types. These	numbers	can
	    be changed (in /etc/fstab),	and by trial and error,	 CS
	    have   arrived   a	set  of	 values	 for  certain  host
	    combinations, and network topologies.  Future  versions
	    of	NFS will fix this automatically, but we	cannot rely
	    on this percolating	through	all implementations.

       Note almost all the configuration information starts off	 in
       human readable (ascii) unix (or VMS, or Xerox...) files,	and
       are thus	very easily set	up. In almost all cases, these	can
       be  set	up once	and for	all on one machine, and	distributed
       via rdist  or  some  similar  utility.  Frequently,  the	 IP
       address of a new	machine	is the only thing that need be set,
       and the rest can	be copied from a master.


       3.  Statistics and Fault	Isolation

       3.1  Statistics

       BSD Unixes have a standard interface to network	statistics.
       Not  only can one set flags to applications to gather stats,
       but also	there a	facilities (netstat, nfsstat) for  querying
       the network interfaces and protocols as to figures like:
















				  - 7 -




       Active Internet connections
       Proto Recv-Q Send-Q  Local Address	   Foreign Address	  (state)
       tcp	  0	 0  localhost.1766	   localhost.sunrpc	  TIME_WAIT
       tcp	  0	 0  localhost.1765	   localhost.sunrpc	  TIME_WAIT
       tcp	  0	 1  pink.login		   pyr1.1023		  ESTABLISHED
       tcp	  0	 0  pink.1023		   vax1.login		  ESTABLISHED
       tcp	  0	 0  pink.login		   white.1022		  ESTABLISHED
       tcp	  0	 0  pink.telnet		   spider2.5051		  ESTABLISHED


       Name  Mtu   Net/Dest    Address	    Ipkts   Ierrs Opkts	  Oerrs	Collis Queue
       ie0   1500  ucl-ethern  pink.cs.ucl. 601969  29	  296592  41	504    0
       lo0   1536  loopback-n  localhost    8346    0	  8346	  0	0      0


       Routing tables
       Destination     Gateway	       Flags	Refcnt Use	  Interface
       192.9.18.1      europa.cs.ucl.a UGH	0      0	  ie0
       192.9.18.2      europa.cs.ucl.a UGH	0      0	  ie0
       ucl-ethernet    pink.cs.ucl.ac. U	14     239164	  ie0
       default	       cisco.cs.ucl.ac UG	0      218	  ie0
       ulcc	       brooklyn.cs.ucl UG	0      0	  ie0
       192.9.17	       europa.cs.ucl.a UG	0      0	  ie0
       btrl	       manhatten.cs.uc UG	0      0	  ie0
       ucl-net-b       purple.cs.ucl.a UG	0      0	  ie0
       mrc-net	       manhatten.cs.uc UG	0      0	  ie0
       loopback-net    localhost       U	6      8140	  lo0
       hirst	       tacoma.cs.ucl.a UG	0      0	  ie0


       Similar facilities exist	on routers (e.g. CISCO/Bridge)	and
       MAC bridges.

       The reliability of error	statistics depends very	 much  upon
       the   network   interface.  A  Sun  has	an  extremely  high
       performance AMD Lance ethernet interface, which can gather a
       great  deal  of information about collisions and	CRC errors.
       DEC equipment is	fairly notorious  in  being  inaccurate	 at
       gathering such information.

       3.2  General_Traffic_Tool

       We also have a general traffic monitoring package  from	the
       National	  Science   Foundation,	 called	 NNStat.  This	was
       develoepd for the US equivalent of JANET	 (NSFnet),  and	 is
       fairly powerful.

       It can run the following	functions:













				  - 8 -



	 1.   Distributed Data Acquisition

	 2.  Centralized Data Collection

       3.3  Fault_Finding

       Faults can be in	the network, a	host  interface,  a  higher
       level  protocol,	 or  the  host	itself.	 Faults	in datagram
       networks, such as IP based ones,	are fairly hard	to find. CS
       have a number of	tools for investigating	faults:

	  o ping derived ticmp.

	    TCP/IP has a built in management protocol called  ICMP.
	    This is a simple echo facility which runs within IP. An
	    echo packet	is sent	(which can contain timestamps)	and
	    running  IP	 hosts	or  routers are	obliged	to reply. A
	    fairly simple program exists (ping)	to do just this	and
	    to	repeat,	 gathering  stats  as  to  percentage  lost
	    packets and	round trip delays.  This  is  very  useful,
	    since  coupled  with knowledge of the topology, one	can
	    map	out the	 connectivity  state.  A  further  pair	 of
	    facilities,	 source	 routing and route recording, allow
	    the	 topology  to  be  determined  even  under  dynamic
	    changes.

	    A version  of  ping	 allows	 IP  level  traffic  to	 be
	    generated  at a given rate,	and so determine throughput
	    and	turnaround capabilities	of routers and hosts.

	  o Transport monitoring programs exist. The  most  general
	    facility  is  etherfind,  which allows a Sun to monitor
	    all	ethernet traffic promiscuously.	 A  tool  based	 on
	    this  is tcpdump, which understands	the working of TCP,
	    and	allows performance and protocol	functionality to be
	    analysed very extensively.

	  o Applications  can  be  monitored  using  etherfind	 or
	    tcpdump,  or  netwatch  on a PC, although these are	all
	    limited to ethernet.

	    In general,	we prefer to alter the applications to	add
	    logging, and an example of a well monitored	application
	    is the mail	 system.  Application  parameters  are	not
	    usually  terribly  relevant	 to  performance and so	not
	    many tools are available.  The main	exception  is  nfs,
	    where  nfsstat  allows  enough  stats to be	gathered to
	    allow  tuning  of  the  protocol  parameters  mentioned
	    above:













				  - 9 -





	    Network Disk:
	    rcv	0  snd 0  retrans 0  (NaN%)
	    notuser 0  noumatch	0  nobuf 0  lbusy 0  operrs 0
	    rseq 0  wseq 0  badreq 0  stimo 0  utimo 0	iseq 0

	    Server rpc:
	    calls      badcalls	  nullrecv   badlen	xdrcall
	    68170      0	  0	     0		0

	    Server nfs:
	    calls      badcalls
	    68128      0
	    null       getattr	  setattr    root	lookup	   readlink   read
	    0  0%      15340 22%  68  0%     0	0%	23723 34%  63  0%     16832 24%
	    wrcache    write	  create     remove	rename	   link	      symlink
	    0  0%      4210  6%	  1204	1%   802  1%	38  0%	   35  0%     0	 0%
	    mkdir      rmdir	  readdir    fsstat
	    2  0%      2  0%	  5430	7%   379  0%

	    Client rpc:
	    calls      badcalls	  retrans    badxid	timeout	   wait	      newcred
	    17785      10	  271	     177	276	   0	      0

	    Client nfs:
	    calls      badcalls	  nclget     nclsleep
	    17785      10	  18082	     297
	    null       getattr	  setattr    root	lookup	   readlink   read
	    0  0%      4177 23%	  3  0%	     0	0%	5275 29%   172	0%    4470 25%
	    wrcache    write	  create     remove	rename	   link	      symlink
	    0  0%      2653 14%	  518  2%    22	 0%	105  0%	   18  0%     0	 0%
	    mkdir      rmdir	  readdir    fsstat
	    0  0%      0  0%	  306  1%    66	 0%


       4.  Security and	Access Control

       Access control in TCP/IP	networks is fairly simple. There is
       no  standard  for security or access control for	IP packets,
       although	many routers have mechanisms for filtering on a	per
       address	(network  and  or  host, source	and or destination,
       similarly to many MAC bridges).

       TCP  uses  the  notion  of  well	 know  ports  to   identify
       applications.  Since  remote  login  (telnet/rlogin), remote
       execution (rsh) and  file  transfer  (ftp/rcp)  all  involve
       access	to  a  system,	the  well  known  ports	 for  these
       applications are	 system	 privileged,  and  only	 privileged
       programs	 normally  use	such ports (0-1023). It	is possible
       (though fairly difficult) to write a client half	of such	 an











				  - 10 -



       application  for	 an un-secure machine (e.g. a PC). However,
       the  applications  also	require	 authentication	  of   user
       (telnet/ftp/smtp	 and  rlogin/rcp/rsh)  by password and user
       login, and so managed systems' security is not subverted.

       However,	there are mechanisms for equivalencing machines, so
       that  users/applications	 are  then  not	required to present
       passwords -  i.e.  are  not  authenticated.  This  does	not
       present	any  danger  if	 all  machines	are  managed by	one
       privileged authority, and no others are trusted.	However, if
       an  un-managed  machine	masquarades  as	 one of	the managed
       ones, it	may gain access.  This is usually prevented,  since
       to  do so entails using an existing managed machines address
       and name. If that machine is on the net,	it will	ring alarms
       to  say that a duplicate	host exists, and usually the target
       machine	will  fail  to	communicate   with   the   spoofer.
       Unfortunately, if the doppelganger chooses to work only when
       the real	managed	machine	is down, then it may well  succeed.
       In  our	experience,  this  is  very difficult to achieve in
       practice, and has not yet happened within CS.

       If it did, there	are two	solutions: disallow  equivalencing,
       and or disallow name/addresses of managed machines when they
       are down. [Note	-  Berkeley  applications  authenticate	 on
       source	machine	  address  and	name,  and  user  name	and
       password].


       5.  Electronic Mail

       Electronic mail management is a huge area in itself.

       Mailboxes have to be associated with users logins, and where
       users  may  have	 logins	 on many machines the location of a
       user's mailbox may not be obvious. The CS solution has  been
       to  minimise  the  number  of mail system machines, and hide
       delivery	from users by whatever mechanism  (e.g.	 over  NFS)
       easiest.

       Management of mailsystems in the	wider  context	(inter-site
       mail)  is  beyond  the scope of this note, but it is assumed
       that for	UCL, this would	come into line	with  JNT  policies
       fairly  straigtforward,	rather than rely on TCP/IP standard
       mechanisms.


















				  - 11 -



       6.  Summary

       We have covered TCP/IP network management from  a  viewpoint
       somewhat	 coloured  by  the  use	of Unix, and the underlying
       assumption that we are mainly concerned with ethernet  based
       LANs. Most of the mechanisms carry over fairly simply to	WAN
       networks, and indeed CS have found no special problems  with
       our  TCP/IP  connection	to  the	 US or for that	matter with
       managing	the IP aspects of the Admiral high speed network).

       If a conclusion is to  be  drawn,  it  is  that	centralised
       control	 of   configuration   information,   with  periodic
       distribution of the relevant data greatly  eases	 the  task,
       and that	very large systems can be managed by a small number
       of people given this approach.

       The only	area where insufficient	tools exist for	real  fault
       finding is Ethernet fault tracking. However, this is general
       to that type of LAN, and	really has little or nothing to	 do
       with TCP/IP, except where broadcast protocols are used.







































-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Oct 88 17:40:54 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        George michaelson <munnari!ditmela!george@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: what is dynamic IP address assignment


Hi george,

 i agree with Craigs original categories and your questions. 
There's 2 cases of dynamic address allocation requirement.

Moving hosts and mobile hosts arent the same thing.

Moving hosts:
400 people move from a's to b's, plug in their client machines, and want
to access files/mail at sites a's. Then use dynamic IP address allocation
on the net they plug their moving hosts into, and allow the
applications to sort the rest out.

Mobile hosts:
10000 people flying around europe want their IP packets from thei
laptops on the plane to be *routed correctly and optimally* while the
PSPF route is constantly shifting and the nearest gateway is
constantly changing - solve this a different way with an extra level
of addressing and routing - they are a mobile net so have a new
routing/addressing scheme a la landmark routing/etc


jon

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Oct 88 03:17:33 EDT
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Network Management Tools
Section 4 (Security and Access Control) is incorrect:  The Berkeley
protocol "rsh" and "rcp" have *no* mechanism for password authentication.
In order for them to be used at all, the user *must* have set up
"equivalence", stating that so-and-so on that.host is allowed access.
"rlogin" will use either "equivalence" or password checking.

Any host where any "equivalence" exists is exactly as secure as any
other host on the same broadcast subnet.  Thus, if there is a PC
with a client for either protocol on the subnet, users of "rsh" and
"rcp" are wide open to spoofing.

The "rexec" protocol *always* requires a password, and so we provide a
PC client for it (it only exists as a library routine on 4bsd).  We
also use it as a fallback in our "rmt" and "tar" clients, so they can
be used without much risk (4bsd versions use "rsh").

James VanBokkelen
FTP Software Inc.
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Oct 88 11:49:15 CDT
From:      "Stuart Levy" <slevy@uc.msc.umn.edu>
To:        stjohns@beast.ddn.mil
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  Net 3 assignment
Is WHOIS also supposed to list networks which are registered with the NIC,
but not approved for Internet connection?  Many of these show up in
the Internet Numbers RFC's even though WHOIS does not list them at present.

	Stuart Levy
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Oct 88 14:35:36 CDT
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Bridge vs. router, or $ vs. $$$$$$
I would like to thank everyone that replied to a query I made concerning
subnetting, or lack thereof, on our campus network.  However, one consistent
theme in all of the responses that I received was that people could not
understand why we were even considering installing a campus network with
bridges instead of routers.  I would like to share my reasoning with you
so that you can correct me if I am wrong.

We are just beginning our campus network.  Our initial efforts will be to
connect 6 buildings together with fiber optic cable and a MAC layer bridge
in each building.  Ultimately, we hope to connect about 30 buildings, although
we don't have a timetable for completion of the net.  The only router on
the campus net for now is a Proteon P4200 which connects our campus net to
SURANET.
As I see it, routers offer one advantage over bridges.  They offer better
firewall protection in case network problems occur.  Bridges, on the other hand,
seem to offer two distinct advantages over routers.  First, they are protocol
independent, i.e., they will pass decnet, tcpip, etc.  And second, they are
much cheaper that routers.  Our state just purchased 4 Proteon P4200's for
about $14,000 each, whereas I am purchasing RETIX bridges for about $1,800
each.  Since at this point, I have no information base from which to predict
traffic volume or problem frequency, and since I don't want initially to
preclude some protocols from running across the campus net, and since bridges
are so much less expensive than routers, the decision was made to use bridges.

Is my reasoning sound, or is there some major flaw that I am not aware of?
Any comments would be welcomed.

One other point was raised by one person, and I don't understand this either.
He was surprised that we were able to get a class B network address since
our initial campus network plans did not include subnetting with routers.
What does subnetting have to do with whether you need a class B network?
If you have more than 255 hosts, which we do, it seems to me that you have
no choice but a class B network.

Mike Rackley
Mississippi State University
Rackley@MsState.BITNET
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Oct 88 19:06:25 CDT
From:      "Joseph P. Thomas" <jpt@uc.msc.umn.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: SLIP over Telnet...

	Yes, it's does seem rather messy to encapsulate IP inside of IP,
however, 3-Com ( Bridge ) is one of those who DOESN'T support SLIP in
the servers, and as I've been told awhile ago, have no plans to do so.
( Since a large number of former Bridge employees have now left, I doubt
that they have anyone who would even contemplate such a project now. )
Anyways, the only physical ports we have on our machines are the consoles.
Since eveything comes in via the "net" ( NSF/ARPA/private ), which is
already taken care of, or dial-in, it would be nice to do away with KERMIT
and run SLIP. Dediacated SLIP lines via pty's would be okay, but a nicer
solution would be to use the UC-Davis async. terminal/slip package, where
the user establishes the connection, and then iof he wishes to run SLIP,
tells the system so. No preconceived notions here. I know I'll end up writing
such a beast if someone else already hasn't, so suggestions other than
running in the server ( which is the best case ) would help.


Joseph Thomas

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 88 23:50:26 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: simultaneous connections

>I do not know whether any 20@aributed systems in the Internet take 
>advantag?

TK TCP design feature but at the time of its design,
>TCP held symmetry to be a highly valuable characteristicnet!hiVint Cerf

Doesn't the FTP "Three Party Model" depend on symetric, peer-peer
connections? There are several FTP's out there that support Three Party, not
to mention Braden & DeSchon's work on BFTP.

Ross Patterson
Center for Computer and Information Services
Rutgers University
#! rnews 733
Path: munnari!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!n
are4n!princeton!udel!mmdf
From: 97331812%

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 88 05:04:47 GMT
From:      daveb@gonzo.UUCP (Dave Brower)
To:        comp.protocols.tcp-ip
Subject:   Dumb question:  ping w/o icmp support?

A number of the machines I use support only the tcp and udp protocols. 
I'd really like to be able to ping from them.  Is there any hope, short
of harrassing the vendors?

thanks,
-dB

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 88 08:30:50 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip
Subject:   TCP suite for DEPCA-A

Seeking reviews from anyone who has successfully used DEC DEPCA and any
TCP (TELNET and FTP) alternately with PCSA (1.9 or 2.x).  I understand
the Enet cards and PC architecture do  not lend to running PCSA and TCP
at the same time on the same PC.  NFS?  Thanks in advance, /Ev/
-- 
 suned1!efb@elroy.JPL.Nasa.Gov   sun!tsunami!suned1!efb   efbatey@NSWSES.ARPA
    Any statements / opinions made here are mine, alone, not those of the    
    United States, the DoD, the Navy, the Congress, the Judiciary, nor ...   

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 88 10:46:40 GMT
From:      barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC question

In article <155100002@ishmael>, cball@ishmael writes:
>What are the ifconfig command arguments in the boot file(/etc/rc.boot
>in SunOS 3.5)?

The netmask was added a year ago when we converted to subnets.
It was the first thing I tried when this problem surfaced with
SunOS 4.0.

I did get a message from Sun about this problem.

Make sure the ifconfig line has `hostname` on the line.
The standard rc.local is missing it.

	Bruce Barnett

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 88 16:46:20 GMT
From:      dftsrv!tomc@ames.arc.nasa.gov  (Tom Corsetti)
To:        tcp-ip@sri-nic.arpa
Subject:   weird arps
Hi,
I've been using tcpdump on a sun to filter on arps.  The reason I'm
doing this is to build a table of ether addresses for each ip-address, or
hostname that I trap.  While building the table, I'm flagging machines
with duplicate ip addresses for a given ether add, and vice-versa.
Thus far, I've noticed some pretty strange things on our net.  I really
don't understand where some of this stuff is coming from.  I would appreciate
any help in understanding what's going on.  In the first example, I show
arp who-has broadcasts from some computers with pretty strange addresses.
(addresses like 0.0.0.144):

15:35:59.87  8:0:89:d0:1:1 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.144 tell 0.0.0.6
15:35:59.91  8:0:89:d0:23:25 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.243 tell 0.0.0.144
15:53:20.64  8:0:89:c0:17:47 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.110 tell 0.0.0.142
15:53:20.64  8:0:89:d0:16:2 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.110 tell 0.0.0.70
15:53:20.64  8:0:89:d0:23:28 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.110 tell 0.0.0.147
15:53:20.64  8:0:89:d0:17:81 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.110 tell 0.0.0.200
15:53:20.66  8:0:89:d0:37:98 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.110 tell 0.0.0.66
15:53:20.66  8:0:89:d0:1:1 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.110 tell 0.0.0.6
15:53:20.68  8:0:89:d0:23:27 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.110 tell 0.0.0.146
10:37:37.56  sunjpg ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.120.149 tell 0.0.120.149



Next, I have alot of computers that send out arps for the ether addresses of
the net broadcast mask.  What's going on here??

16:24:31.52  2:60:8c:6:35:71 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell vlsi2.gsfc.nasa.gov
16:46:24.74  8:0:20:1:90:df ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell ltpsun.gsfc.nasa.gov
16:46:24.74  2:60:8c:5:82:37 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell cad564.gsfc.nasa.gov
16:46:24.74  2:60:8c:6:35:71 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell vlsi2.gsfc.nasa.gov
16:46:24.76  2:60:8c:1:2:64 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell cad663.gsfc.nasa.gov
16:46:24.76  8:0:14:10:15:80 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell vlsi6.gsfc.nasa.gov
16:46:24.76  8:0:14:10:32:58 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell vlsi5.gsfc.nasa.gov
16:46:24.76  80:0:10:30:2e:6f ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell david.gsfc.nasa.gov
16:46:24.76  80:0:10:30:a:6b ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell dipac.gsfc.nasa.gov
16:46:24.76  80:0:10:30:2e:8a ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell dadc.gsfc.nasa.gov
16:46:24.80  aa:0:4:0:cb:18 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell censun1.gsfc.nasa.gov
10:15:30.78  2:60:8c:5:82:37 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell cad564.gsfc.nasa.gov


I have seen both of the above quite frequently on our net.  The latter case,
braodcast for the broadcast mask occurs very regularly (I'm glad computers
don't send responses to those!!!)  Thanks in advance for any enlightening
remarks on this.
                                                  - Tom Corsetti
                                                    tomc@dftsrv.gsfc.nasa.gov
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 88 19:41:24 GMT
From:      haas@wasatch.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   Re: tcp-ip terminal servers

I've been evaluating terminal servers and am not too pleased with the results
so far.  The application I have in mind is a little different from the usual-
I want to put a TCP/IP/Ethernet server back-to-back with a Zenith Z-LAN NCU
so that users of the Z-LAN network can access Ethernet machines and
vice versa.  Therefore the TCP/IP server must simultaneously provide both
modem control and hardware flow control in both directions.  This rules out
use of the cisco ASM and the Encore Annex, sigh, both of which look like
good boxes in most other respects.

3com/Bridge loaned me a CS/1 for evaluation and it does the modem and flow
control fine.  Unfortunately it doesn't support rlogin and refuses to ping
a multihomed host (like, for example, cs.utah.edu).  I talked to the
software support guy at 3com/Bridge about this and his reply was that they
had no plans to support rlogin, and you shouldn't give two IP addresses
to the same host (!).  So from that I think we can safely say that they
can't support their software.

Incidentally I wrote their President a letter asking him to please get
onto the Internet so I wouldn't have to play telephone tag for a week
at a time to talk to his guys.  He never replied to the letter.

Right now I have a Micom/Interlan NTS-100 downstairs to evaluate.  Their
literature says it supports rlogin but I can't fin any sign of rlogin
in the actual firmware - plus there are a slew of obvious bugs.  Probably
I just got an old copy of the firmware but their tech support guys aren't
returning phone calls - at least not with any degree of rapidity.  I know
somebody on the net posts from Interlan - it seems, however, that this is
not known to their management, or at least is not thought of as a way
to support customers, because the local rep has been beating on them to
improve the accessibility of their support and he reports that Micom/
Interlan management isn't even aware that this channel exists.

So would all you folks with brilliant ideas about how to solve this
problem mind coming out of the woodwork with your bright ideas?

Thanks in advance  -- Walt Haas   haas@cs.utah.edu   utah-cs!haas

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 12:11:53 GMT
From:      dave@clsib21.UUCP (David P. Hansen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on the DR11

I am looking for support of tcp-ip on the DR11 interprocessor comm
board for Unix (sysV or Berkley). Anyone have any leads on a driver? 
Thanks. 
-- 
	ONLY BIG BABIES				David P. Hansen, CLSI, Inc.
	ARE PRO-CHOICE!				320 Nevada Street
	----------------			Newtonville, MA  02160
Internet: dave%clsib21.uucp@bbn.com	UUCP: {...}bbn!clsib21!dave

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 12:18:35 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re: simultaneous connections

Three party FTP doesn't depend on the symmetry of TCP connection
opening.  I suppose there is a kind of symmetry there, but it is not at
the TCP connection handling level.  Although there are two servers
involved in a three party FTP operation, they are executing different
state machines, so to speak; the client that sets up the three party
FTP implicitly selects this "polarity" by sending the PASV command to
one of the servers and not to the other one.  Once this has been done,
there is a specific assignment of duties implicit in the protocol.
(The server which received the PASV command does only a passive open on
the data connection, and the other one does an active open.  There is a
similar allocation of responsibility for closing the connection,
subject to the same twist as in two party FTP where the sender of a
file in a file-structure, stream-mode transfer always initiates the close.)

My admittedly superficial reading of the BFTP RFC led me to believe that
BFTP doesn't alter any of this, but rather provides a different sort of
a frontend to the FTP operation.

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

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Oct 88 16:45:07 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Mike Rackley <RACKLEY@MSSTATE>, tcp-ip@sri-nic.arpa
Subject:   Re: Bridge vs. router, or $ vs. $$$$$$

>As I see it, routers offer one advantage over bridges.  They offer better
>firewall protection in case network problems occur.  Bridges, on the other
>hand,
>seem to offer two distinct advantages over routers.  First, they are protocol
>independent, i.e., they will pass decnet, tcpip, etc.  And second, they are
>much cheaper that routers.  ...
>
>Is my reasoning sound, or is there some major flaw that I am not aware of?
>Any comments would be welcomed.

I think I already responded in the first round, but I'll do it again.
We have the same setup here at Michigan State University, and I certainly
think your reasoning is sound.  We have a significant sized Decnet
community, and several other protocols which are in use between departments,
at varying points across campus.  A "flat" network makes a lot of sense here.

I have heard a lot of doomsaying about this type of configuration, but in
my experience I have not seen an undue number of network problems caused
by such a large ethernet community.  Our biggest problem is generally
the level of background/broadcast traffic on our net, of which a significant
portion comes from misconfigured hosts.  However, even these misconfigurations
are relatively benign; mistakes in configuration seldom affect other hosts.
Like your configuration, we only have one external gateway.  This makes life
very simple when it comes to routing issues.

Probably our biggest concern with this network is how soon we will run out
of capacity on a single 10Mb backbone.  But our solution there will be to
migrate our largest users to fiber.  When we do so, we'll have to begin
worrying about real routing, gateways, etc.

I don't see where you're in any serious trouble with your plans.

Doug Nelson
Michigan State University
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Oct 88 17:13:21 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Harry Saal <hjs@lindy.Stanford.EDU>, Ted Hardie <HARDIE@SRI-NIC.ARPA>, barnett@vdsvax.steinmetz.ge.com, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Broadcast RPC question
Your detailed trace allows me to confirm my suspicions.  The hosts which
reply with a "port unreachable" are definitely in error.  They are
making the following mistakes (I'm using the Host Requirements draft
RFC as my point of reference):

1.  A host should not send an ICMP error reply in response to a
    link layer broadcast (section 3.2.2).

2.  The Dec host either a) thinks that 3.0.0.0 is a valid IP broadcast
    address, in which case it should not send an ICMP error reply (section
    3.2.2), or b) doesn't think 3.0.0.0 is an IP broadcast address,
    in which case it should have discarded the datagram immediately upon
    receipt as not being destined for itself (section 3.2.1.9).

3.  The host is responding with an IP source address of 3.0.0.0, rather
    than its own IP address (sections 3.3.5 and 3.3.6).

To be fair, there are quite a number of TCP/IP implementations which make
one or more of these mistakes.  It will be nice to have the Host Requirements
RFC in hand to use as a definitive reference for such errant software.

Even now while this document is still in draft form, I'd recommend pointing
vendors in this direction if they aren't already aware of its existence, and
if they are, I'd suggest that they read it.

Doug Nelson
Michigan State University
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Oct 88 17:36:19 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Tom Corsetti <dftsrv!tomc@ames.arc.nasa.gov>, tcp-ip@sri-nic.arpa
Subject:   Re: weird arps
>Hi,
>I've been using tcpdump on a sun to filter on arps.  The reason I'm
>doing this is to build a table of ether addresses for each ip-address, or
>hostname that I trap.  While building the table, I'm flagging machines
>with duplicate ip addresses for a given ether add, and vice-versa.
>Thus far, I've noticed some pretty strange things on our net.  I really
>don't understand where some of this stuff is coming from.  I would appreciate
>any help in understanding what's going on.  In the first example, I show
>arp who-has broadcasts from some computers with pretty strange addresses.
>(addresses like 0.0.0.144):
>
>15:35:59.87  8:0:89:d0:1:1 ff:ff:ff:ff:ff:ff 0806
>             60: arp who-has 0.0.0.144 tell 0.0.0.6
>  [text deleted]
>
>Next, I have alot of computers that send out arps for the ether addresses of
>the net broadcast mask.  What's going on here??
>
>16:24:31.52  2:60:8c:6:35:71 ff:ff:ff:ff:ff:ff 0806   60: arp who-has
>  128.183.255.255 tell vlsi2.gsfc.nasa.gov
>  [text deleted]
>
>I have seen both of the above quite frequently on our net.  The latter case,
>braodcast for the broadcast mask occurs very regularly (I'm glad computers
>don't send responses to those!!!)  Thanks in advance for any enlightening
>remarks on this.
>                                                  - Tom Corsetti
>                                                    tomc@dftsrv.gsfc.nasa.gov

Your project sounds very similar to one that I have been working on for a
year or so now.  It does exactly the same thing - building a list of ethernet
addresses, and recording any IP addresses in use.  It also records all
protocol types being used by each system, and the types of destination
IP broadcast addresses seen in IP and ARP packets (all zeroes/ones,
network + zeroes/ones, subnet + zeroes/ones).

I have seen the same types of strangenesses on my network.  There was
recent discussion somewhere about the first - these are being sent out
by Suns which boot across the network, during the boot process.  I'd
like to see some more details about how the IP address is picked out.
If I remember right, this is no longer a problem with SunOS 4.0.

The latter (ARPs to a broadcast address) are sent out by hosts which aren't
configured to have the correct broadcast address themselves.  I have seen
such ARPs with various combinations of mismatched broadcast address
configurations.

Doug Nelson
Michigan State University
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 15:55:10 GMT
From:      joel@VAX.FTP.COM (Joel Gartland)
To:        comp.protocols.tcp-ip
Subject:   (none)

Date: Tue, 18 Oct 88 11:13:27 EDT
From: joel@vax.ftp.com (Joel Gartland)
Message-Id: <8810181513.AA01177@vax.ftp.com>
To: tcp-ip@src-nic.arpa
Subject: ftp option PASV
Cc: joel@vax.ftp.com


Well, 
	I've been mucking with the passive option and have found a machine that
at least thinks it understands the option. Me, I'm not so sure.
	When I send it the PASV command, the server responds:

	    227 Data transfers will passively listen to 128,127,2,150,p1,p2

(p1,p2 being the port), which makes sense except that 128,127,2,150 is
*my* address.
	Now, as I read the RFC(959), shouldn't the server send it's own
address and port it's listening on? If I'm misunderstanding, please let me 
know; if I'm correct, can anyone tell me of a host that does implement PASV
correctly so I can test it??

					Thanks much
						Joel Gartland
						FTP Software

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 16:25:43 GMT
From:      sean@geac.UUCP
To:        comp.protocols.tcp-ip
Subject:   PICK and TCP/IP

Is anybody aware of an implementation of the PICK operating
system that includes TCP/IP in any way ?

Any information would be welcome.  If there's sufficient
interest, I'll post a summary of mail replies.

Thanks very much !!

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 16:32:26 GMT
From:      pete@NCSC.ARPA (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Micro-based multiuser O/S TCP/IP


    We at NCSC are trying to identify products (O/S + driver + card) to
    implement on a micro (Compaq, Z-248, AT ...) that supports multi-user/
    multitasking, on our IEEE 802.3 TCP/IP LAN.  Any recommendations and/
    or leads would be greatly appreciated.

                                          Thanx
    Pete Fernandez
    pete@ncsc.arpa
    (904) 234-4120
    Naval Coastal Systems Center
    Code 4430
    Panama City, FL 32407Z[?1;07  

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 16:42:20 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: simultaneous connections

>(The server which received the PASV command does only a passive open on
>the data connection, and the other one does an active open.  There is a

Yes, that's right. I went back and re-read RFC959, and that's exactly what
happens. 20/20 hindsight reminds me that what I suggested couldn't possibly
work, since it would mean opening a connection between well-known ports on
two different systems, precluding the use of three-party FTP between those
systems by more than one user at a time. 

>My admittedly superficial reading of the BFTP RFC led me to believe that
>BFTP doesn't alter any of this, but rather provides a different sort of
>a frontend to the FTP operation.

Yes, but it depends on the three-party model. I meant it as an illustration
of why three-party FTP exists (there are a number of people out there who
regard it as "hokey").

Ross Patterson
Rutgers University
Center for Computer and Information Services

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 16:51:40 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Question on UDP under BSD UNIX.

Here's an interesting question for you UNIX TCP/IP Folks,

    Refering to the recvfrom() functions in the 4.2/4.3 socket
    library.

    When an application receives a UDP packet, the SENDERS address is
    located in the sock_add_in structure passed in the recvfrom()
    call.  Is there any way for an application to get the DESTINATION
    address.  I.E. I would like to know if this UDP packet was directed
    to me, or the broadcast address.

    If the answer is no, is there any way of filtering out one or the
    other (i.e. receive only broadcasts or don't receive broadcasts).

You can respond to tcp-ip or directly to me "scottr@csc-lons.arpa".  I
will post a summary.

------------------------------------------------------------------------
Scott W. Rogers		Computer Sciences Corporation - Systems Division
AT&T: (703) 876-1363	3160 Fairview Park Dr. - Falls Church, VA 22152
Fax:  (703) 876-4072	Internet: scottr@csc-lons.ARPA
------------------------------------------------------------------------

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 17:02:47 GMT
From:      netcoor@NCS.DND.CA (DRENET Coordinator)
To:        comp.protocols.tcp-ip
Subject:   Sendmail Questions


As I don't see much discussion of Sendmail on this list, I suspect This may be
the wrong forum for my question. If so, please direct me to the appropriate
place.

I have just picked up Sendmail 5.59 from ucbarpa.berkeley.edu. After loading
it onto disk, I printed off the documentation. The documentation describes
two subdirectories "cf.named" and "cf.hosttable" which contain sendmail
configuration files. As we are now running BIND, I want to use the cf.named
subdirectory, but it is not in the Sendmail distribution I picked up.
Where can I find the appropriate files, or who can I contact to get them?

Can someone tell me what the major differences are for hosttable
based configuration files versus named based configuration files? Are there
particular pitfalls to watch for? Is there a document describing setting
up a named based configuration file similar to the one Eric Fair wrote
for hosttable based configuration files? If so, where can I find it?


Bob Bradford				netcoor@ncs.dnd.ca
DREnet Coordinator			(613) 998-2520

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 17:22:55 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   Re: tcp-ip terminal servers

In article <417@wasatch.UUCP> haas@wasatch.UUCP (Walt Haas) writes:
>I've been evaluating terminal servers and am not too pleased with the results
>so far.  The application I have in mind is a little different from the usual-
>I want to put a TCP/IP/Ethernet server back-to-back with a Zenith Z-LAN NCU
>so that users of the Z-LAN network can access Ethernet machines and
>vice versa.  Therefore the TCP/IP server must simultaneously provide both
>modem control and hardware flow control in both directions.  This rules out
>use of the cisco ASM and the Encore Annex, sigh, both of which look like
>good boxes in most other respects.
>
>So would all you folks with brilliant ideas about how to solve this
>problem mind coming out of the woodwork with your bright ideas?
>
	You are right about the products:  those that do good telnet
and rlogin don't understand serial lines and those that understand
serial lines (like U-B, Sytek, ...) don't do rlogin, domain name, etc
very well.

	I think part of the problem is trying to minimize the number
of pins supported.  The vendors want to use just four or five signals
when we need eight (but not always all at the same time).  Using eight
signals only allows six circuits on a 50 pin telco connector.  Using
six or fewer signals lets you put eight circuits on a 50 pin telco.  I
don't think a lot of the hardware design goes much beyond those decisions.

	It's my opinion that, at a minimum, your serial interface
needs to support a connect/disconnect hardware handshake and a
ready/clear flow control handshake.  connect/disconnect is usually
dtr/dsr or dtr/cd.  Hardware flow control is usually rts/cts.  But no
matter; you can always remap the flow control or conn/disconn signals
to other pins on your punchdown or in your RJ/DB adaptor.  The point
is that you need the functionality of handshaking upon connect and
disconnect (how many of you have systems that don't close sessions
when the modem line is dropped?) and you need hardware flow control
sometimes (you always need flow control, either soft or hard).  Of
course, you need three data signals.  That's seven or eight signals
depending on whether dsr and cd have different characteristics.

	I can get along without ring indicator, speed, and busy out,
but there are those who will have difficulty without those signals.
Could we at least agree on the need for connect/disconnect and
hardware flow control handshaking?  If they could give us that much we
could build most of our terminal clusters and modem pools and host
front ends.

	Of course, there will be problems with "normally on" versus
"normally off" and toggle times (oops, the vax missed the toggle,
sorry your session is still open), but that's why we have to get away
from RS232 eventually.

	Kent England, Boston University

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 17:47:09 GMT
From:      egisin@watmath.waterloo.edu (Eric Gisin)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question:  ping w/o icmp support?

In article <440@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes:
> A number of the machines I use support only the tcp and udp protocols. 
> I'd really like to be able to ping from them.  Is there any hope, short
> of harrassing the vendors?

Yes, port SUN RPC to your machines (see your comp.sources.unix archives).
Run the etc/portmap server, this will serve as a RPC/UDP ping server.
Then write a 20 line ping client that does an RPC
call to the portmapper's NULL procedure (described in the documentation).
PC/NFS has this program, they call it nfsping.

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 17:55:17 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp option PASV

Joel:

You are right, they are wrong, and TOPS-20 FTP does the right thing
(at least about this, and assuming nobody broke it while I wasn't looking).
I will leave it to you to try to think of a TOPS-20 host that might
allow you to use anonymous FTP to get files whose names you more or
less know already.......

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

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 18:53:36 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   Re: simultaneous connections

Bill,

You are correct.  BFTP makes use of the server-server, or third party,
model of FTP described in RFC 765.  It does not depend on simultaneous
TCP connections.

To illustrate this:  Using third party file transfer, or more specifically
BFTP, there are three TCP connections.  There is an FTP control connection 
between BFTP and each of the FTP servers, and a data connection between 
the two FTP servers. (P) indicates a passive open, and (A) indicates an 
active open of the TCP connection.

In the case where BFTP sends the "PASV" command to the Source Host, the
Destination Host opens the data connection:

		         ------
		        | BFTP |
		        |Daemon|
		         ------
		     (A)        (A)
		     ^		  ^
      control conn. /		   \ control conn.
		   v		    v
	         (P)		    (P)
	      ------                -----------
	     |Source|		   |Destination|
	     | Host |		   |   Host    |
	     | FTP  |(P)<------>(A)|   FTP     |
	     |Server|	   	   |  Server   |
	      ------   data conn.   -----------


Where BFTP sends the "PASV" command to the Destination Host, the Source
Host opens the data connection:

		         ------
		        | BFTP |
		        |Daemon|
		         ------
		     (A)        (A)
		     ^		  ^
      control conn. /		   \ control conn.
		   v		    v
	         (P)		    (P)
	      ------                -----------
	     |Source|		   |Destination|
	     | Host |		   |   Host    |
             | FTP  |(A)<------>(P)|   FTP     |
	     |Server|	   	   |  Server   |
	      ------   data conn.   -----------


The BFTP Daemon always initiates both control connections.

--Annette

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 19:30:30 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   [John Hight:  Re: simultaneous connection]

How quickly we forget. John is absolutely correct and I have a bum chip
in my memory socket. RFC-759, which describes MPM, does not mention the
source port number, but does specify 45 as the destination port number.
I presume the distinction is mentioned in the SRI report that we eventually
adopted for the tests and bakeoffs (heck, I even left fossilized
implementations of MMM on the fuzzballs). Want I should send you an MMM
message for old time's sake?

Dave sends

----- Forwarded message # 1:

Received: from louie.udel.edu by Huey.UDEL.EDU id ac16312; 18 Oct 88 13:23 EDT
Received: from [128.18.4.204] by Louie.UDEL.EDU id aa16532; 18 Oct 88 13:22 EDT
Received: from localhost by coco4 (3.2/5.00)
	           id AA05998 for mills@louie.udel.edu; Tue, 18 Oct 88 10:23:17 PDT
Message-Id: <8810181723.AA05998@coco4>
To: Mills@louie.udel.edu
Subject: Re: simultaneous connection 
In-Reply-To: Your message of Thu, 13 Oct 88 12:47:44 -0400.
             <8810131247.aa23878@Huey.UDEL.EDU> 
Return-Receipt-To: hight@tsca.istc.sri.com
Date: Tue, 18 Oct 88 10:23:13 PDT
From: John Hight <hight@tsca.istc.sri.com>


>The only scenario I know in the Internet archeology is the relic
>Multimedia Message Protocol (MPM), in which the message agents used
>the same TCP port number for both the source and destination ports.

Dave,

Not that it's very important, but I believe you are mistaken here. MPM
used different specific port numbers for both the source and
destination ports (45 and 46 to be precise). And it's Message
Processing Module.

John Hight
SRI International

----- End of forwarded messages

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 19:34:06 GMT
From:      fluke!ssc-vax!bruce@beaver.cs.washington.edu  (Bruce Stock)
To:        tcp-ip@sri-nic.arpa
Subject:   RE: Wierd ARPs

To: uw-beaver!mit-eddie!bloom-beacon!gatech!ukma!mailrus!ames!dftsrv!tomc
Subject: Re: weird arps
In-reply-to: your article <73@dftsrv.gsfc.nasa.gov>
Tom
	You are just seeing the tip of the iceberg, believe me.  I see the
	same things and LOTS more on our net using the Data General Sniffer
	(a Lanalyzer).  There are so many pathologies on the typical, 
	unmanaged ethernet, it would make your head sore.

	RE what you saw:  The 0.0.0.number is probably coming from Kinetics
	fastpath boxes.  They do a "double ARP", first using a TCP arp, then
	using an Appletalk ARP.  The tCP ARP is asking for 0.0.0.(appletalk
	network number).  This unnecessary TCP ARP can be turned off by
	certain incantations which Kinetics can tell you about.

	The second business of ARPing for the broadcast address is an artifact
	of the current state of implementation half-vastness where about half
	of your net doesnt recognize the broadcast address that the other 
	half uses.  

				Regards, Bruce Stock
					uw-beaver!ssc-vax!bruce
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 19:51:21 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)

Joel,

Try a fuzzball, such as dcn1.arpa (128.4.0.6), but don't try it too
hard, since its only a wee thing and is likely to curse you in Gaelic
if abused. It does return its own address plus manufactured port, but
the implementation dates from Long Ago and may never have been prperly
tested.

Dave

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 20:45:07 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Bridge vs. router, or $ vs. $$$$$$


>As I see it, routers offer one advantage over bridges.  They offer better
>firewall protection in case network problems occur.  Bridges, on the other
>hand,
>seem to offer two distinct advantages over routers.  First, they are protocol
>independent, i.e., they will pass decnet, tcpip, etc.  And second, they are
>much cheaper that routers.  ...
>
>Is my reasoning sound, or is there some major flaw that I am not aware of?
>Any comments would be welcomed.

I think I already responded in the first round, but I'll do it again.
We have the same setup here at Michigan State University, and I certainly
think your reasoning is sound.  We have a significant sized Decnet
community, and several other protocols which are in use between departments,
at varying points across campus.  A "flat" network makes a lot of sense here.

I have heard a lot of doomsaying about this type of configuration, but in
my experience I have not seen an undue number of network problems caused
by such a large ethernet community.  Our biggest problem is generally
the level of background/broadcast traffic on our net, of which a significant
portion comes from misconfigured hosts.  However, even these misconfigurations
are relatively benign; mistakes in configuration seldom affect other hosts.
Like your configuration, we only have one external gateway.  This makes life
very simple when it comes to routing issues.

Probably our biggest concern with this network is how soon we will run out
of capacity on a single 10Mb backbone.  But our solution there will be to
migrate our largest users to fiber.  When we do so, we'll have to begin
worrying about real routing, gateways, etc.

I don't see where you're in any serious trouble with your plans.

Doug Nelson
Michigan State University

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 21:13:21 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast RPC question

Your detailed trace allows me to confirm my suspicions.  The hosts which
reply with a "port unreachable" are definitely in error.  They are
making the following mistakes (I'm using the Host Requirements draft
RFC as my point of reference):

1.  A host should not send an ICMP error reply in response to a
    link layer broadcast (section 3.2.2).

2.  The Dec host either a) thinks that 3.0.0.0 is a valid IP broadcast
    address, in which case it should not send an ICMP error reply (section
    3.2.2), or b) doesn't think 3.0.0.0 is an IP broadcast address,
    in which case it should have discarded the datagram immediately upon
    receipt as not being destined for itself (section 3.2.1.9).

3.  The host is responding with an IP source address of 3.0.0.0, rather
    than its own IP address (sections 3.3.5 and 3.3.6).

To be fair, there are quite a number of TCP/IP implementations which make
one or more of these mistakes.  It will be nice to have the Host Requirements
RFC in hand to use as a definitive reference for such errant software.

Even now while this document is still in draft form, I'd recommend pointing
vendors in this direction if they aren't already aware of its existence, and
if they are, I'd suggest that they read it.

Doug Nelson
Michigan State University

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 21:48:50 GMT
From:      sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   Re: tcp-ip terminal servers

In article <417@wasatch.UUCP> haas@wasatch.UUCP (Walt Haas) writes:
>Right now I have a Micom/Interlan NTS-100 downstairs to evaluate.

Forget it! We have one of these (obtained from Black Box) and
the software is ancient. Their implementation of telnet is poor
and they don't support two way ports (which would allow you
to dial in or out). You have to disable the modem talk modes
because they interfere with the telnet protocol (when will
somebody fix this). Most of all, the support (which used to
be quite good with this company), really stinks.

What would be ideal is a server which had downloadable software
and a standard cpu (like a 68000), which would allow you to
write your own code and load it. That way you could support
SUPDUP, telnet, ROSE, or any old protocol that you like. In
the meantime, get LSI-11s and do it yourself.

Sean McLinden
Decision Systems Laboratory

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 88 21:54:47 GMT
From:      aramis.rutgers.edu!geneva.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: weird arps
Sun's, at least running SunOS 3.2, use their serial number as their IP
address until they get far enough up to know their real IP address.
I suspect that's why you're seeing addresses like 0.0.0.144.
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 88 01:21:19 GMT
From:      dyer@arktouros.MIT.EDU (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip terminal servers

May I suggest that people remove comp.unix.aux from their followups
to this subject, since there's little here to do with A/UX.
---
Steve Dyer
dyer@arktouros.MIT.EDU
dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyer

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Oct 88 07:49:42 EDT
From:      snorthc@relay-nswc.navy.mil
To:        acornrc!asylum!romkey@ames.arc.nasa.gov, tcp-ip@sri-nic.arpa
Subject:   Re: NetBIOS over TCP/UDP
What is NetBIOS used for?

A couple years ago we managed to get our first versions of PCIP
running (CMU and FTP SW).  I was sure management would be happy.
The PCs could speak the native tongue of the internet, exchange
files with various hosts running TCP/IP, even send mail.  I figured
a massive bonus would surely come my way.  No, instead it was a
swift kick.

We want TRANSPARENT file access, mail, and print services for our
PCs, said management.

So we studied PC NFS, NetBIOS/TCP, and Locus.  None of these solutions
satisfy file, mail, print services 100%.  

That however is the answer [ I think] to the question what is NetBIOS
for.  Even just as a file service, it had potential.  What choked it
for us was the memory required to make it work.  Why would anyone
want transparent file access?  Sigh.  To this day, I wouldn't want
to be held to this, but supposedly users do not want to be bothered
to log in via FTP to xfer a file.  They want the file to be referenced
as drive "F:".

These are a different breed of users than those who subscribe to
info TCP I suspect.  Anyway, that is all in the past.  The future
is my question.  I read in the OS/2 SDK for the Lan manager that it
is very MS-NET and NetBIOSy.  Assuming for a minute (big assumption)
OS/2 has some success in the marketplace, is this a boost for NetBIOS?
Will we have to take NetBIOS/ISO (NetBIOS/GOSIP in my case) seriously?

Stephen Northcutt

Caveat: there are questions that have no right answer.  Discussions of
NetBIOS tend to lead to such questions.
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 88 03:54:44 GMT
From:      att!pacbell!belltec!jom@ucbvax.Berkeley.EDU  (Jerry Merlaine)
To:        tcp-ip@sri-nic.arpa
Subject:   BootP Protocol
A while back someone posted a Public Service (how's that for copyrighted
no-cost software?) BootP server program in C, I believe someone at Stanford.
Would that someone or someone else please send me a copy?
Now that we need it, it's been vaporized...

Thanks

Jerry O. Merlaine
pacbell.com!belltec!jom
{lll-crg,ames,pyramid}!pacbell!belltec!jom
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 88 11:46:46 GMT
From:      dunigan@THDSUN.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   Re:  weird arps

15:35:59.87  8:0:89:d0:1:1 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.144 tell 0.0.0.6
15:35:59.91  8:0:89:d0:23:25 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 0.0.0.243 tell 0.0.0.144

the preceding messages are from Kinetics/Macintosh/Appletalk boxes
perhaps attempting to communicate their presence and possibly appletalk number,
usually seen when Kinetics box is booted


16:24:31.52  2:60:8c:6:35:71 ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell vlsi2.gsfc.nasa.gov
16:46:24.74  8:0:20:1:90:df ff:ff:ff:ff:ff:ff 0806   60: arp who-has 128.183.255.255 tell ltpsun.gsfc.nasa.gov

the above usually arise from a mixture of machines with different broadcast
masks (e.g., in your case, some machines are running with old
mask convention of 128.183.0.0 rather than present practice of 128.183.255.255),so when one of the older mask machines sees a UDP broadcast (e.g. whod)
from a machine under the newer mask, it fires off the ARP

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 88 11:49:42 GMT
From:      snorthc@RELAY-NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP

What is NetBIOS used for?

A couple years ago we managed to get our first versions of PCIP
running (CMU and FTP SW).  I was sure management would be happy.
The PCs could speak the native tongue of the internet, exchange
files with various hosts running TCP/IP, even send mail.  I figured
a massive bonus would surely come my way.  No, instead it was a
swift kick.

We want TRANSPARENT file access, mail, and print services for our
PCs, said management.

So we studied PC NFS, NetBIOS/TCP, and Locus.  None of these solutions
satisfy file, mail, print services 100%.  

That however is the answer [ I think] to the question what is NetBIOS
for.  Even just as a file service, it had potential.  What choked it
for us was the memory required to make it work.  Why would anyone
want transparent file access?  Sigh.  To this day, I wouldn't want
to be held to this, but supposedly users do not want to be bothered
to log in via FTP to xfer a file.  They want the file to be referenced
as drive "F:".

These are a different breed of users than those who subscribe to
info TCP I suspect.  Anyway, that is all in the past.  The future
is my question.  I read in the OS/2 SDK for the Lan manager that it
is very MS-NET and NetBIOSy.  Assuming for a minute (big assumption)
OS/2 has some success in the marketplace, is this a boost for NetBIOS?
Will we have to take NetBIOS/ISO (NetBIOS/GOSIP in my case) seriously?

Stephen Northcutt

Caveat: there are questions that have no right answer.  Discussions of
NetBIOS tend to lead to such questions.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 88 12:08:48 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   Re: DEC LANBRIDGE 100/Sun 4 problems?


   >We have a multi-segment ethernet connected by supposedly transparent
   >filtering bridges.  Recently we were unable to reach the lone node, a
   >Sun4/260  on the far side of a DEC LANBRIDGE 100.  Upon investigation we
   >found that the problem was due to the DEC bridge filtering out broadcast
   >packets, thus preventing arp requests from reaching the Sun4.  If the
   >Sun4's physical ethernet address was entered by hand there was no problem.
   >Monitoring the Sun4 side of the bridge revealed a bunch of packets that
   >the network analyser called "Lanbridge Management Packets".  Toggling
   >power to the Lanbridge fixed things.


Newer models of DEC's LANBRIDGE 100 apparently will "learn" the
broadcast address if there is a sick engine on the Ether that
emits packets with a source addresss of all 1's (broadcast).
Having stashed the broadcast address in its filter table,
the LANBRIDGE will no longer pass broadcast packets, so engines
behind the LANBRIDGE that require broadcast (e.g. ARP) no longer
work!  (We had a sick microvax 2000 that would issue the bogus
packets with broadcast source address occasionally and gum up
three or four of our LAN100s)  Older LAN 100s survive.  I think
DEC may have a ROM patch or some such, but the only recourse
is to restart the LAN100 (can be done remotely however)
  AND, of course, see if you can "catch" the engine that is
sending packets with a broadcast source address -- a challenge!

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 88 13:19:14 GMT
From:      thorin!adams!hewitt@mcnc.org  (W. Joe Hewitt)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: weird arps
In article <Oct.18.17.54.45.1988.2434@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>Sun's, at least running SunOS 3.2, use their serial number as their IP
>address until they get far enough up to know their real IP address.
>I suspect that's why you're seeing addresses like 0.0.0.144.

The addresses like 0.0.0.144 are coming from a Kinetics AppleTalk to
Ethernet bridge.  The K-boxes used this invalid ARP before the 0x809b
Kinetics AppleTalk-Ethernet and 0x80f3 AppleTalk ARP packet types were
assigned.  There is a small software configuration which will
eleminate them.  If anyone would like to know how to do this, just let
me know.  

Cheers!

-- Joe
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 88 16:55:36 GMT
From:      marcel@dx7.UUCP (Marcel Bernards)
To:        comp.protocols.tcp-ip
Subject:   Domain name server on SUN 4-280 Help !!!

We are trying to set up a nameserver for our IP-domain.
Our TCP-IP domain exists of a number of SUN workstations and a
large amount of UB NIU-130's and NIU-180's.

We want to use a SUN-4/280 as the root domain name server.
The only thing we want to do is use UB-NIU tcp telnet>>connect <hostname>
instead of telnet>>open <IP-Address> [port nr] ( = user unfriendly )
Currently we didn't succeed due to a problem in the named.db database ( ??)
We think we did all things right .... 
{ as in the example in the SUN manual [RFC ....] }

Here the examples of the related files:
*** named.boot ***
;
;       boot file for name server
;
domain          ECN-NLERF
primary         ECN-NLERF       /etc/named.db

**** named.db ***
@       IN      SOA     ecn.ECN-NLERF.          root.ecn.ECN-NLERF. (
                1.1     ;version
                3600    ;refresh
                300     ;retry
                3600000 ;expire
                3600 )  ;minimum
        IN      NS      ecn.ECN-NLERF.
localhost IN    A       127.0.0.1
loghost IN      CNAME   localhost
ecn     IN      A       130.112.1.1
zappa   IN      A       130.112.1.5
dx7     IN      A       130.112.1.7
ibis    IN      A       130.112.1.87
niu53   IN      A       130.112.1.53
*** piece off named.run debugging log file ***
dqp->dq_addr 127.0.0.1 d_dfd 9
dqp->dq_addr 130.112.1.1 d_dfd 10
Ready to answer queries.
prime_cache: priming = 0
datagram from 130.112.1.53, 10  34304 (23)
ns_req()
HEADER:
        opcode = QUERY, id = 17515, rcode = NOERROR
        header flags:  rd
        qdcount = 1, ancount = 0, nscount = 0, arcount = 0

QUESTIONS:
        ZAPPA, type = A, class = IN

req: nlookup(ZAPPA) id 17515 type=1
req: missed 'ZAPPA' as '' (cname=0)
findns: using cache
findns: using hints
findns: No root nameservers?
req: answer -> 130.112.1.53 10 (34304) id=17515 Local
***** end **
Who knows what i did wrong ?? 

please E-mail.
=============== Local UNIX & Network System administrator ===================
Marcel Bernards                             | e-mail: ..!mcvax!ecn!marcel
Netherlands Energy Research Foundation, ECN | Telex : 57211 REACP NL
P.O. Box 1                                  | Fax   : -31 2246 4480
1755 ZG Petten (NH), Holland.               | Phone : -31 2246 4342
--------------------------------------------+--------------------------------

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 02:46:34 GMT
From:      cmf@cisunx.UUCP (Carl M. Fongheiser)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question:  ping w/o icmp support?

In article <527@mks.UUCP> egisin@watmath.waterloo.edu (Eric Gisin) writes:
>In article <440@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes:
>> A number of the machines I use support only the tcp and udp protocols. 
>> I'd really like to be able to ping from them.  Is there any hope, short
>> of harrassing the vendors?
>
>Yes, port SUN RPC to your machines (see your comp.sources.unix archives).
> [more words about RPC and the portmapper]


Sure, you could do that, but I think it'd be a LOT easier to implement the
UDP echo protocol.  Likely to have a lower overhead cost, too.

				Carl Fongheiser
				University of Pittsburgh
				...!pitt!cisunx!cmf
				cmf@unix.cis.pittsburgh.edu
				cmf@pittunix.BITNET

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 03:11:13 GMT
From:      vskahan@lgnp1.MASA.COM (Vince Skahan)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Gated drops routes in Win/TCP 3.1

I'm trying to run dynamic routers on Win/TCP Vaxes and have been having
no luck at all (although all Bsd4.2 systems around here run routed just
fine).

The problem is that the routes DO appear when gated starts up but these
routes disappear after (about) 20-45 minutes if nobody is using the
gateway (subnet) in question.  

Can anyone post or email how to set up gated.conf for the Woolagong
product to do plain vanilla dynamic routing??? I have all the
Apollos/Suns/Ultrix systems with routed running just fine but the VMS
systems just don't want to cooperate...

Thanks.


-- 
				Vince Skahan
	UUCP: lgnp1!vskahan			Internet: skahan@boeing.com

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 10:51:37 GMT
From:      grn@stl.stc.co.uk
To:        comp.protocols.tcp-ip
Subject:   Specification of Berkeley networking utilities

Is there a public domain specification of the Berkeley networking
utilities such as rlogin? 

The type of question that I would expect to be able to answer given a
specification is the use made out-of-band data in rlogin for example.

A second and related question is why does the SunOS 4.0 implementation
of rlogin and rsh reject connections with client port numbers in the
range 0-512? My desire for specification of the interoperability
requirements of these networking utilities was partly prompted by the
failure of our local rlogin implementation to interwork with the new
Sun implementation.

Regards,
        Gary Nebbett           STL, London Road, Harlow, Essex  CM17 9NA, UK
grn@stl.stc.co.uk <or> ...uunet!mcvax!ukc!stl!grn <or> PSI%234237100122::GRN

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 11:28:36 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question:  ping w/o icmp support?

In article <527@mks.UUCP: egisin@watmath.waterloo.edu (Eric Gisin) writes:
:In article <440@gonzo.UUCP:, daveb@gonzo.UUCP (Dave Brower) writes:
:: A number of the machines I use support only the tcp and udp protocols. 

You mean they're in violation of the RFC's? :-( ICMP is an integral
part of IP, and  it's got to be in there. Presumably you mean there's
no user-accessible interface to ICMP services.

:: I'd really like to be able to ping from them.  Is there any hope, short
:: of harrassing the vendors?
:
:Yes, port SUN RPC to your machines (see your comp.sources.unix archives).
:Run the etc/portmap server, this will serve as a RPC/UDP ping server.
:Then write a 20 line ping client that does an RPC
:call to the portmapper's NULL procedure (described in the documentation).
:PC/NFS has this program, they call it nfsping.

Minor nit: "nfsping" actually calls the null procedure of the
mount daemon rather than that of the portmapper, since we figured this was
more useful to the user. This was probably the wrong choice, since one
can find out if the mount daemon is up in a variety of ways (rpcinfo,
showmount, etc.).
-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:garnold@sun.com               +------------------------------------------+

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 12:04:31 GMT
From:      doug@ICASE.EDU (Doug Peterson)
To:        comp.protocols.tcp-ip
Subject:   ftp problem


My aplogies to those who see this more than once.

Given the following configuration of Sun's (except for A) The Sun's run
Sun OS 3.5.1, and the nameserver patch kit. The nameserver appears to
work fine. We've been using it for about 6 weeks. "A" is any Internet
site.


          ---------------------------|~|----------------------
                         |                      |Any.site.domain
                         |128.102.23.51      ---------
                     -----------             |       |
                     |  3/180   |            |  A    |
                     |          |            ---------
                     ------------
                         |
                         |    192.42.142
             ------------------------------------------------
                   |            |             |
                   |            |             |
               --------     ---------      --------
               | 3/50 |     |  3/50 |      | 3/50 |
               --------     ---------      --------
                work1

Ftp from the 3/180 (ICASE.EDU) to A works fine. Ftp from any 3/50 to A
(in this case csab.larc.nasa.gov) is shown below.

work1% ftp csab.larc.nasa.gov
Connected to csab.larc.nasa.gov.
220 csab FTP server (Version 4.148 Mon Mar 21 10:01:27 PST 1988) ready.
Name (csab.larc.nasa.gov:doug): 
Password (csab.larc.nasa.gov:doug): 
331 Password required for doug.
230 User doug logged in.
ftp> ls
ftp: bind: Can't assign requested address
ftp> quit
221 Goodbye.

I'd appreciate any suggestions to help solve this problem. Mail, rlogin
et. al. appear to be working fine.

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 865-4090
FTS: 928-4090
doug@icase.edu

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 12:32:26 GMT
From:      menges@menges.cs.unc.edu (John Menges)
To:        comp.protocols.tcp-ip
Subject:   SNMP/SGMP/ASN.1 information request


I'm implementing an SNMP proxy server for some bridges and gateways
that don't support SGMP or SNMP.  The first part of this project
is for a class I'm taking this semester, so I'm on a short time
schedule.

Can anyone out there help me find any of the following,
preferably via anonymous ftp?  I can spend some money,
but it has to be a small amount for me to get it through
the university system in a short period of time.  I can
spend larger amounts for the longer-term project, as it's
not so time constrained.

1.  Any SNMP server/client code.
2.  Any SGMP server/client code.
3.  Any ASN.1 documentation, or conversion code.

Also, any relevant documentation.  I have the following:

idea0011-00.txt.1
idea0011-01.txt.1

and I am aware of the existence of SGMP RFCs, though I haven't
searched for them yet.  Is there another idea?  I thought I saw
a reference to idea0011-02 at one point but I didn't see it
at sri-nic.arpa. Also, does idea0011-01 supercede idea0011-00?
Are the ASN.1 specs (ISO International standards 8824 and 8825)
available via anonymous ftp, or can I call or mail someone to
get them?  Is there a cost?  Does anyone have SNMP or SGMP
packet descriptions or sample packets they could mail me?

I'll be glad to package up what I find out and post it, if the
contributor(s) ok it.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 13:19:40 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Net 3 assignment

My system is flakey and I may have answered this.

Yes, WHOIS is supposed to list ALL networks, even those not approved
for connection.  to get a network number, you have to fill out a form
and the NIC enters that data in the WHOIS database so it can keep
track of who owns what number.

Mike

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 15:04:47 GMT
From:      steve@umiacs.UMD.EDU (Steven D. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re:  ftp problem


   You should check your ifconfigs in /etc/rc.boot to be sure they're really
happening.  (Best check:  type b -sb at the monitor prompt, then do the
stuff in rc.boot by hand, including the ifconfig.)  I've seen (and reported
to Sun) a problem where diskless nodes will seem to work OK if they learn
their IP address purely via reverse ARP, but the address in the ifnet
structure has garbage where it should have zeroes, and binding local
addresses fails when that garbage gets compared to zeroes somewhere else.
The ifconfig stuffs the address into the interface structure properly.  I
suspect that this problem is in all SunOSes up to (but possibly not
including) 4.0.

   I'll also bet that the ifconfig is failing on the clients because of some
interaction with YP and the nameserver.  You might try putting the client IP
addresses directly into their ifconfig lines in rc.boot and see if that
helps.

   (Does it sound like this has happened to me before?)

	-Steve

Spoken: Steve Miller    Domain: steve@mimsy.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 16:18:07 GMT
From:      zehntel!kinetics!billn@ucbvax.Berkeley.EDU  (Bill Northlich)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: weird arps

The 806 arps with no bits in the protocol address except the rightmost 8 bits
(0.0.0.x) are what we call "old-style Appletalk Arps (AARP)".

With "Ethertalk" Apple specifies a version of arping to use for Appletalk.
Prior to Ethertalk, we (I personnaly must take the blame) threw together
some mods to standard if_ether.c to allow our in-kernel Appletalk code to talk
to others of it's ilk.  Hence the rule "if the left 3 bytes of the 0800 
(IP) protocol address are zeros, then it's an Appletalk ARP".

Our plan was to "do it right" in a future release, and send an 806 packet
with an 809b (Appletalk) protocol type.  Unfortunately we knew of systems which
did not check the protocol type in their ARP modules, and reasoned that it would
be less damaging to the world for some machines to wind up with wierd IP
addresses in their caches, than to risk crashing machines with broken ARP
modules just because we wanted to do Appletalk on ethernet.

Now Apple has come  out with AARP on a completely different ethernet
type (80f3).  They used a new type primairily as another sop to reality, ie,
on a given machine, if some other bunch of software has reserved type 806, it
may be hard to "get into the pants" of the existing 806 code to add Appletalk
stuff.  This is especially true in VMS.

Currently the only system we know of which uses these old AARP's is the Sequent
running Appletalk.  They refuse to upgrade.  In existing networks, there may
be some Pyramids and/or some Vaxes which have not been upgraded.  Also, our
Appletalk router boxes can be configured to do old-style AARP, but they don't
as a normal thing.  In general, there is no need to have old AARP unless you
have a Sequent.  We have a Sequent.  Hardware-wise, the most reliable UNIX
machine I've ever used.
/bill
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 88 19:01:24 GMT
From:      doug@ICASE.EDU (Doug Peterson)
To:        comp.protocols.tcp-ip
Subject:   ftp problem

My ftp problem is fixed. Here's the sequence of events that led to
is conception.

I changed my workstation net to a new Class C address, updated
/etc/hosts on my server, and rebult my YP database. I made all the other
required changes (I thought). However, I overlooked the /etc/hosts on all
my diskless clients. (After all, they boted, rlogin, rsh, et. al. worked)
No user here initiated an ftp session FROM THEIR WORKSTATION until
yesterday. A few days after installing the new IP address, someone
noticed that /etc/hosts on their workstation still had the old IP
addresses in it. I replaced those tables with the current ones just
for consistency's sake, but didn't reboot the workstations. (I use
an rcp script for such things.)

It turns out that ypserv (and related daemons) use an image of the
YP database (on the clients, anyway), that they get when they first
start up. If any of the files are changed, they don't update their
image. The bizarre thing here is that the daemons on the clients
get their image from the client copy of the host tables, not the
YP database, but only when they start up. Thus, ftp would use the
nameserver to get a connection to a remote host, but the ftp sub-command
(e.g. ls) would use the CLIENT version of the data, which was apparently
obtained from a different source than the ftp command itself. Is this
a bug in the ftp-YP interface???

Restarting the daemons (read rebooting the workstations) fixed everything!

The credit for this discovery goes to Sharon Beskenis (sdo@csab.larc.nasa.gov)
a long-time friend and colleague. She talked me into trying a reboot.
Thanks, Sharon!!

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 865-4090
FTS: 928-4090
doug@icase.edu

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 01:31:01 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question:  ping w/o icmp support?

>> A number of the machines I use support only the tcp and udp protocols. 
>> I'd really like to be able to ping from them.  Is there any hope, short
>> of harrassing the vendors?

I think there is a confusion here.  If they support TCP and UDP they
have to support IP.  (IP is the lower layer on top of which TCP and
UDP are implemented.)  Ping is implemented using ICMP echo.  The IP
specifications require all IP implementations to support ICMP echo.
Now technically speaking all the spec requires is that your machine
must respond to echos sent by other machines.  But once the mechanism
is present, I'd be a bit surprised if there isn't a way to issue a
ping yourself.  So I'll bet there's some way to make it work.  What
implementations are we talking about?

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 02:55:55 GMT
From:      mailrus!uflorida!manatee.cis.ufl.edu!esj@ames.arc.nasa.gov  (Eric S. Johnson)
To:        tcp-ip@sri-nic.arpa
Subject:   NSFnet map

I have here in front of me a nice little map of the NSFnet. Local nets
are in ovals, gateways are little circles, regional nets nicely labeled,
lines connecting it all which represent the wires (loosely). 
Looks like it might have been done in postscript.

The problem is that this map is a couple of years old.  (somebody
passed it out at a meeting, back when we were first preparing for our
SURAnet connection)

Id sure like to get a hold of a recent version of this map. Or anything
else that might help me visualize the physical setup of the NSFnet.

Any Ideas?

Ej
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 05:07:42 GMT
From:      kurt@pprg.unm.edu (Kurt Zeilenga)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.modems
Subject:   Data Encryption Devices

I am collecting data on existing and future devices for securing
high-speed IP networks (LAN and WAN).  Though our main interest
is encryption of data crossing non-secure phone circuits (DS0
thru DS3) in a wide-area research networks, however, other issues
are of concern.

Please send pointers, information and any comments directly to me.
I will provide a summary of responses to the network.

Thanks, Kurt

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Oct 88 14:22:59 CDT
From:      Shane Davis <SHANE%UTDALVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP/IP on the DR11

>    ONLY BIG BABIES                David P. Hansen, CLSI, Inc.
>    ARE PRO-CHOICE!                320 Nevada Street
>    ----------------            Newtonville, MA  02160
>Internet: dave%clsib21.uucp@bbn.com    UUCP: {...}bbn!clsib21!dave

*FLAME ON*

Why don't you set up your own distribution list if you wish to make such
statements (right-to-life-request?)? I'm sure I'm not the only one who takes
offense at having his mbox soiled with such unsolicited political crap. If
we wanted to hear that, we would subscribe to right-to-life-request...

I don't know, but might this even constitute misuse of the ARPAnet?

*FLAME OFF*

If I missed something (perhaps pro-choice means something else here? sure...),
I apologize...

--Shane Davis
  Systems Programmer, Univ. of Texas at Dallas Academic Computer Ctr.
  SHANE@UTDALVM1{.BITNET|.dal.utexas.edu}
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 12:53:45 GMT
From:      keith@tarantula.spider.co.UK (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip terminal servers


I am surprised to hear that the provision/non-provision of rlogin on
terminal servers is a major issue. It seems to me that while rlogin does have
some advantages over telnet, it is a protocol designed specifically for use
between Unix systems. Terminal servers are usually not Unix systems, and so
some of the assumptions which rlogin makes tend to break down.

The two main advantages of rlogin over telnet are probably that of
authentication and passing across of terminal type. For client use it is
possibly reasonable to build these into a non-Unix system. However, when
using the server as a milking machine, these advantages are lost, there
being no defined mechanism for passing authentication and terminal type
information across the serial lines.

In any case, I have yet to see a Unix system with rlogin which does not
support telnet too. Telnet also has the advantage of being an officially
defined and well-documented protocol, which is more than can be said for
rlogin.

One approach is of course to have a terminal server which runs Unix, but
I suspect supporting Unix (hardware, licensing etc) puts the per-box cost
up enough that rather more lines are needed to keep the per-line cost down.
Having to fit all these lines onto one server has the side-effect of
restricting the number of control signals provided on each line.

With SpiderPort, we go for a small, cheap unit with a smaller number (10) of
lines, but with full bi-directional hardware flow and modem control signals
on each line. We did not go for rlogin support, largely for the reasons
detailed above. On the other hand, if rlogin's a big issue with users, and
we've missed something, then I'd be interested to hear what.

Keith Mitchell

Spider Systems Ltd.		Spider Systems Inc.
65 Bonnington Road		12 New England Executive Park
Edinburgh, Scotland		Burlington, MA 01803
+44 31-554 9424			+1 (617) 270-3510

keith@spider.co.uk		keith%spider.co.uk@uunet.uu.net
keith@uk.co.spider		...!uunet!ukc!spider!keith

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Oct 88 20:13:59 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   SIGCOMM '88 -- Call for papers



			PRELIMINARY CALL FOR PAPERS

			 ACM SIGCOMM '89 SYMPOSIUM*

		 Communications Architectures and Protocols

			       Austin, Texas

			       September 1989



	The  symposium  provides  an  international  forum  for  the
	presentation  and discussion of communication network appli-
	cations and technologies, as well  as  recent  advances  and
	proposals  on  communication architectures, protocols, algo-
	rithms, and performance models.  Authors are invited to sub-
	mit  full  papers  concerned  with both theory and practice.
	The areas of interest for the symposium include, but are not
	limited  to  the  following: analysis and design of computer
	network architectures and algorithms, innovative results  in
	local  area networks, computer-supported collaborative work,
	network interconnection and mixed-media networks, high-speed
	networks,  resource  sharing in distributed systems, distri-
	buted operating systems and databases,  protocol  specifica-
	tion, verification, and analysis.

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

	Submit 5 copies of each paper to the program  chairman:  Dr.
	Mohamed  Gouda,  Computer Sciences Department, University of
	Texas at Austin, Austin  TX  78712,  USA;  Telephone:  (512)
	471-9532; EMAIL: gouda@cs.utexas.edu

	For more information about the symposium, contact  Dr.  L.H.
	Landweber,  General  Chair, Computer Sciences Dept., Univer-
	sity of Wisconsin, 1210 W. Dayton St.,  Madison,  WI  53706;
	Tel: (608) 262-1204; EMAIL: landweber@cs.wisc.edu.

			    STUDENT PAPER AWARD

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

			      IMPORTANT DATES

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

			    SYMPOSIUM COMMITTEE

	General Chair:  L.H. Landweber, University of Wisconsin, USA
	Program Chair:  M. Gouda, University of Texas, USA
	Local Arrangements: M. Gouda, University of Texas, USA

*Pending ACM approval.
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 14:54:58 GMT
From:      dftsrv!jha@ames.arc.nasa.gov  (Ashok Jha)
To:        tcp-ip@sri-nic.arpa
Subject:   Decnet and TCP/IP LAN and WAN performance

 Hi,

   Wo would like to have any or all performance tests that have been
performed giving stastistics of performance (WAN/LAN) of DECnet and or TCP/IP
file transfer and or interactive sessions. Please send e-mail or the
references if they are published. Any combination of tests are welcome. We
will attempt to consolidate if appropriate.

    
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 16:36:12 GMT
From:      netcoor@NCS.DND.CA (DRENET Coordinator)
To:        comp.protocols.tcp-ip
Subject:   Sendmail Questions Unanswered


My original posting of the following was unanswered. I am posting it again
in hopes that some one can help or at least direct me to help.

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

As I don't see much discussion of Sendmail on this list, I suspect this may be
the wrong forum for my question. If so, please direct me to the appropriate
place.

I have just picked up Sendmail 5.59 from ucbarpa.berkeley.edu. After loading
it onto disk, I printed off the documentation. The documentation describes
two subdirectories "cf.named" and "cf.hosttable" which contain sendmail
configuration files. As we are now running BIND, I want to use the cf.named
subdirectory, but it is not in the Sendmail distribution I picked up.
Where can I find the appropriate files, or who can I contact to get them?

Can someone tell me what the major differences are for hosttable
based configuration files versus named based configuration files? Are there
particular pitfalls to watch for? Is there a document describing setting
up a named based configuration file similar to the one Eric Fair wrote
for hosttable based configuration files? If so, where can I find it?


Bob Bradford				netcoor@ncs.dnd.ca
DREnet Coordinator			(613) 998-2520

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 16:36:41 GMT
From:      kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
To:        tcp-ip@sri-nic.arpa
Subject:   Re: NSFnet map
In article <18684@uflorida.cis.ufl.EDU> 
esj@manatee.cis.ufl.edu (Eric S. Johnson) writes:
>
>Id sure like to get a hold of a recent version of this map. Or anything
>else that might help me visualize the physical setup of the NSFnet.
>
>Any Ideas?

	That is something the MERIT person who handles NSFnet
relations in the MERIT NIC (is that Sue Gerlach?) told me that MERIT
was doing.  Not sure how far they have gotten, but you can check via
anonymous ftp to nis.nsf.net and see what's there today. 
	She said they might collect submitted maps, if that proves to
be workable, so polish up your campus network map  :-)
	(Now let's see APPLE-SHIFT-<what?> will output a postscript
file from MacDraw, hmmm.... I wish I could figure out how to dump my
net map out into a ps file.  Any ideas? :-)

	It would be excellent if MERIT would publish some ps maps.
NSFnet has an interesting physical and logical topology.  It's
difficult to understand how they are working the backbone without a
couple of nice maps showing the differences between their physical
link architecture and their software architecture.
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 17:36:41 GMT
From:      pf@csc.ti.com (Paul Fuqua)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question:  ping w/o icmp support?


    Date: Thursday, October 20, 1988  6:28am (CDT)
    From: geoff at eagle_snax.UUCP ( R.H. coast near the top)
    Subject: Re: Dumb question:  ping w/o icmp support?
    Newsgroups: comp.protocols.tcp-ip
    
    In article <527@mks.UUCP: egisin@watmath.waterloo.edu (Eric Gisin) writes:
    :In article <440@gonzo.UUCP:, daveb@gonzo.UUCP (Dave Brower) writes:
    :: A number of the machines I use support only the tcp and udp protocols. 
    
    You mean they're in violation of the RFC's? :-( ICMP is an integral
    part of IP, and  it's got to be in there. Presumably you mean there's
    no user-accessible interface to ICMP services.
    
We have a VMS machine running a locally-hacked version of the CMU TCP/IP
package, and it doesn't respond to ICMP echoes, although it does FTP
just fine (albeit slowly).  Violation or not, it's all we have and
better than Decnet (for our purposes).

    :: I'd really like to be able to ping from them.  Is there any hope, short
    :: of harrassing the vendors?

There are also UDP and TCP echoes, you might try them.

                              pf

Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet:  pf@csc.ti.com (ARPA too, sometimes)
UUCP:   {smu, texsun, cs.utexas.edu, im4u, rice}!ti-csl!pf

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 19:22:59 GMT
From:      SHANE@UTDALVM1.BITNET (Shane Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on the DR11


>    ONLY BIG BABIES                David P. Hansen, CLSI, Inc.
>    ARE PRO-CHOICE!                320 Nevada Street
>    ----------------            Newtonville, MA  02160
>Internet: dave%clsib21.uucp@bbn.com    UUCP: {...}bbn!clsib21!dave

*FLAME ON*

Why don't you set up your own distribution list if you wish to make such
statements (right-to-life-request?)? I'm sure I'm not the only one who takes
offense at having his mbox soiled with such unsolicited political crap. If
we wanted to hear that, we would subscribe to right-to-life-request...

I don't know, but might this even constitute misuse of the ARPAnet?

*FLAME OFF*

If I missed something (perhaps pro-choice means something else here? sure...),
I apologize...

--Shane Davis
  Systems Programmer, Univ. of Texas at Dallas Academic Computer Ctr.
  SHANE@UTDALVM1{.BITNET|.dal.utexas.edu}

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 19:33:39 GMT
From:      haas@wasatch.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   Re: tcp-ip terminal servers

In article <417@wasatch.UUCP>, I wrote:
> 3com/Bridge loaned me a CS/1 for evaluation and it does the modem and flow
> control fine.  Unfortunately it doesn't support rlogin and refuses to ping
> a multihomed host (like, for example, cs.utah.edu).  I talked to the
> software support guy at 3com/Bridge about this and his reply was that they
> had no plans to support rlogin, and you shouldn't give two IP addresses
> to the same host (!).  So from that I think we can safely say that they
> can't support their software.

The reaction to this posting was quite interesting!  Firstly I received a
number of messages from 3com/Bridge people expressing concern that I did
not feel I was getting the quality of support that they tried to provide.
Clearly they are working hard to provide good support.  However many people
who responded did not understand what I expected rlogin to do, so let me
clarify what it does in the cisco and Encore products.  The user does
*not* log in to the terminal server, the user merely specifes use of the
rlogin protocol instead of the TELNET protocol.  Rlogin has the advantage
of making the terminal server much more transparent than a server running
TELNET.  Rlogin is the protocol of choice for users who have a choice.

> Incidentally I wrote their President a letter asking him to please get
> onto the Internet so I wouldn't have to play telephone tag for a week
> at a time to talk to his guys.  He never replied to the letter.

Several people provided uucp paths to Bridge and/or 3com, but none knew
of a username or alias set up to receive requests for service.  One
respondent said that their request to get connected to the Internet was being
held in some sort of queue, but they expected to be connected soon.

> Right now I have a Micom/Interlan NTS-100 downstairs to evaluate.  Their
> literature says it supports rlogin but I can't fine any sign of rlogin
> in the actual firmware - plus there are a slew of obvious bugs.  Probably
> I just got an old copy of the firmware but their tech support guys aren't
> returning phone calls - at least not with any degree of rapidity.

The local rep finally got the current firmware out of them after two tries.
I have it downstairs now and it does have some rlogin support, but there
still seem to be a few problems.  Perhaps I just haven't learned to configure
it correctly yet.  

> I know somebody on the net posts from Interlan ...

It was interesting to note that there was no response from Micom/Interlan
protesting that they try hard to give good service.  This is consistent
with the way they don't answer phone calls.

Be happy, don't worry  -- Walt Haas   haas@cs.utah.edu   utah-cs!haas

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 22:35:22 GMT
From:      system@asuvax.UUCP (Marc Lesure)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   UUCP via Bridge CS/1 box

We currently have about a dozen sites contenting for a single directly
connected modem and would like to offload them to the Bridge box.  We
have a Bridge CS/1 box to which the rest of our modems are connected to.  The
problem we are having is when a uucp site calls us and tries to come
through the bridge.  The uucp system can log in fine, but when uucico starts
executing the process hangs.  We've tried changing different parameters
(i.e., ecmchar, flushvc, flow..., etc), but no luck.  Has anyone else had
this problem and found a solution or the proper parameter settings?

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

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

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 88 23:39:46 GMT
From:      HOSTMASTER@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Connected vs. Unconnected Nets


I would like to clear up a recent confusion over which type of network
the NIC WHOIS data base lists.  Currently, only "connected" networks
are listed in WHOIS.

One would not find any reference to network #3 there because it has
unconnected status, although it is a legitimate number assigned to
General Electric.

-Sue
-------

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 88 00:13:59 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '88 -- Call for papers




			PRELIMINARY CALL FOR PAPERS

			 ACM SIGCOMM '89 SYMPOSIUM*

		 Communications Architectures and Protocols

			       Austin, Texas

			       September 1989



	The  symposium  provides  an  international  forum  for  the
	presentation  and discussion of communication network appli-
	cations and technologies, as well  as  recent  advances  and
	proposals  on  communication architectures, protocols, algo-
	rithms, and performance models.  Authors are invited to sub-
	mit  full  papers  concerned  with both theory and practice.
	The areas of interest for the symposium include, but are not
	limited  to  the  following: analysis and design of computer
	network architectures and algorithms, innovative results  in
	local  area networks, computer-supported collaborative work,
	network interconnection and mixed-media networks, high-speed
	networks,  resource  sharing in distributed systems, distri-
	buted operating systems and databases,  protocol  specifica-
	tion, verification, and analysis.

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

	Submit 5 copies of each paper to the program  chairman:  Dr.
	Mohamed  Gouda,  Computer Sciences Department, University of
	Texas at Austin, Austin  TX  78712,  USA;  Telephone:  (512)
	471-9532; EMAIL: gouda@cs.utexas.edu

	For more information about the symposium, contact  Dr.  L.H.
	Landweber,  General  Chair, Computer Sciences Dept., Univer-
	sity of Wisconsin, 1210 W. Dayton St.,  Madison,  WI  53706;
	Tel: (608) 262-1204; EMAIL: landweber@cs.wisc.edu.

			    STUDENT PAPER AWARD

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

			      IMPORTANT DATES

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

			    SYMPOSIUM COMMITTEE

	General Chair:  L.H. Landweber, University of Wisconsin, USA
	Program Chair:  M. Gouda, University of Texas, USA
	Local Arrangements: M. Gouda, University of Texas, USA

*Pending ACM approval.

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 88 16:01:07 GMT
From:      hwb@MERIT.EDU (Hans-Werner Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet map

Susan Hares actually handles Routing Coordination as part of our NSFNET
project. She is Very Interested in maps of regional networks and, in fact,
has a pretty accurate set already. I am sure she would be happy to also get
campus maps, be it PostScript, ASCII or USMail. We are indeed trying to
make maps available on nis.nsf.net for public FTP (unless people declare
the maps they give us as private). Campus maps could even be of educational
value to others. There are a couple of documents on nis.nsf.net and merit.edu
I think in a "ndoc" ("network documentation") directory, including a PS
map of the logical topoloy. You should be able to find a physical map there
soon, too. The ndoc format may change a little as it is not finalized yet
(and so far we had not even announced it to the regional networks). I am only
posting it here because some question was asked about it. Susan, by the way,
is not part of the Information Services (similar to NIC) group, but part of
my engineering staff. If you have maps for her, please do contact her at
skh@merit.edu. General questions should be send to nsfnet-info@merit.edu 
(which typically gets answered by the Information Services staff).

	-- Hans-Werner

PS: There should be a NSFNET overview article in probably the December issue 
    of ConneXions, which will include both a physical and a logical map. 
    Neither topology has changed since the new NSFNET backbone became 
    operational at the beginning of July.

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 88 16:01:13 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on the DR11


>>    ONLY BIG BABIES                David P. Hansen, CLSI, Inc.
>>    ARE PRO-CHOICE!                320 Nevada Street
 
>Why don't you set up your own distribution list if you wish to make such
>statements (right-to-life-request?)? I'm sure I'm not the only one who takes
>offense at having his mbox soiled with such unsolicited political crap. If
>we wanted to hear that, we would subscribe to right-to-life-request...
>
>I don't know, but might this even constitute misuse of the ARPAnet?
>--Shane Davis

Although I disagree with the person's opinion vehemently I'll defend
to the death his right to say it.

If we tolerate innocuous remarks in net.signatures I'd say we have to
tolerate comments we disagree with also, short of (perhaps)
obscenities or commercialism which is not the issue here.

That is, I find censorship the most offensive of obscenities, and the
Constitution seems to agree. I find your appeal to police authority
particularly stenchworthy.

	-Barry Shein, ||Encore||

Most so-called "pro-lifers" seem to believe a person has rights only
up to the moment of birth.

"If people won't listen to you what makes you think they'll listen
to your T-shirt?" -- Fran Liebowitz

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 88 16:07:23 GMT
From:      hwb@MERIT.EDU (Hans-Werner Braun)
To:        comp.protocols.tcp-ip
Subject:   Regarding NSFNET and maps and such.

By the way, there is a newsletter (LINKLETTER) that we send out to the
regional networks and other interested parties. There have been ten issues
or so so far. If you want to be added to the distribution, please send
your request to nsfnet-linkletter-request@merit.edu

	-- Hans-Werner

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Oct 88  20:23:23 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Regarding NSFNET and maps and such.
> By the way, there is a newsletter (LINKLETTER) that we send out to the
> regional networks and other interested parties. There have been ten issues
> or so so far. If you want to be added to the distribution, please send
> your request to nsfnet-linkletter-request@merit.edu
>
>     -- Hans-Werner

Yes, please add me to the distribution list.
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 88 18:19:26 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?


There are implementations out there that fail to support ICMP.  Some that even
fail to support default routes!  The vendors out there that sell such 'products'
are committing crimes against the Internet community, since we have to debug
problems involving such.  Some vendors which you wouldn't suspect don't even
do ARP!

I personally know of several implementations which are broken in the above ways,
but I'd probably get sued if I spoke up on the net.  I'll let the poor users who
got this stuff because of a 'lowest bid' procurement speak up themselves.  If any
of you vendors that are broken read this note, shame on you for building defective
stuff!

One thing though, most of these implementations find homes on the MILNET, which
still has many hosts directly connected and not relying on gateways as much
as the rest of us...

I think DARPA missed the boat here;  they should have registered TCP/IP as a 
registered trademark like ADA, and required certification.

							Milo

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 88 20:42:03 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   Sendmail Questions


There have been several complaints recently about the
sendmail source on ucbarpa.  I will update/replace it
sometime next week and post a notice.

--keith

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 88 22:52:34 GMT
From:      cyrus@pprg.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Re: DEC LANBRIDGE problems?

In article <8810191208.AA16623@msr.epm.ornl.gov> dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522) writes:
>Newer models of DEC's LANBRIDGE 100 apparently will "learn" the
>broadcast address if there is a sick engine on the Ether that
>emits packets with a source addresss of all 1's (broadcast).

I posted this to comp.dcom.lans, but since the topic came up, I
will post here as well.

There has been A LOT of talk lately concerning DEC LANBridges learning
ff-ff-ff-ff-ff-ff (the broadcast address).  Well, as I posted a few
days ago, I thought that I saw a relation between seeing these packets
and an IBM PC/RT booting.

Well, after some tests, we have hard evidence showing that an IBM PC/RT
running "IBM Academic Operating System 4.3" sometimes produces giant
packets or packets containing garbage upon boot up.  Unfortunately,
the data contained in these packets is mostly 1's which puts some DEC
LANBridges into a bad state.

Below are the results of our tests.  We have not fully tested AIX to
see if it also has the same problems, though preliminary tests indicate
that AIX does NOT have these problems.

Ways which do NOT cause it to generate bogus packets:
	- reboot while running (i.e. using reboot/shutdown/halt/etc)
	- software reset (i.e. CNTRL-ALT-Pause) while running

Ways which DO cause it to generate bogus packets:
	- halt & wait for "halting (via wait)" message -> power off ->
		power on -> normal reboot
	- halt & wait for "halting (via wait)" message -> software reset
		via CNTRL-ALT-Pause @ wait for boot prompt ":" ->
		power off -> power on -> normal reboot
	- simulated power hit (power off while running)


The two places in the boot process that we have seen these bogus packets
produced are:
1) when the ethernet device is probed when the kernel is
   looking for devices (marked with ---> below).

        4.3 BSD UNIX (GENERIC) #1: Fri Sep 23 10:32:48 PDT 1988
            ibmacis@clam:/usr/sys/GENERIC
        
        5799-WZQ (C) Copyright IBM Corporation 1986,1987
        All Rights Reserved
        Licensed Materials - Property of IBM
        
        Using 238 buffers containing 716K bytes
        Memory summary: total 12288K (0xc00000), available 10196K (0x9f5000)
        AFPA marked down pending microcode load and initialization.
        68881 enabled.
        autoconf
        hdc0: card level 0x4b microcode level 0x46 configuration bits 0xc7
        hdc0 adapter f00001f0 IRQ 12 CPU level 4 
        hd0 at hdc0 slave 0
        hd0: hd70e; interleave factor is 1 to 1
        hd1 at hdc0 slave 1
        hd1: hd70e; interleave factor is 1 to 1
        hd2 at hdc0 slave 2
        hd2: hd70e; interleave factor is 1 to 1
        fdc0 adapter f00003f2 IRQ 6 CPU level 4 
        fd0: 1.2M drive
        fd0 at fdc0 slave 0
        stc0 adapter f00001e8 IRQ 12 
        st0 at stc0 slave 0
--->    un0 adapter f4080000 IRQ 3 CPU level 3 
--->    un0: ethernet address 0:dd:0:f8:23:0
        lp0 adapter f00003bc IRQ 7 
        psp0 adapter f0008000 IRQ 2 CPU level 3 
        root on hd0
        configure end

2) and when the ifconfig is done in /etc/rc.local
        ifconfig ${network} inet ${hostname} ${net_flags}

We will be notifying IBM of these problems, but in the
mean time we thought everyone should be apprised of this
problem.

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

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 88 00:15:04 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Decnet and TCP/IP LAN and WAN performance

Ashok,

Please send stamped, self-addressed boxcar plus a couple of weightlifter
types. Be prepared to pay postage from several overseas countries and
to provide staff to comb through an estimated 20,000 electric messages
stashed on several Internet hosts plus numerous conference proceedings
and journal articles. First, however, retrieve a sruffy bibliography
in the file pub/bib.ps on host louie.udel.edu anonymously, then you
get to beat up the authors yourself.

Jeff Mogul at DECWRL has a nice bibliography of TCP/IP performance
articles. The SIGCOMM 88 Symposium has a couple of recent papers as well.
Chase the references plus the RFC and IEN indexes at the NIC (sri-nic.arpa)
and you will find most of the rest.

Dave

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 88 00:23:23 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  Regarding NSFNET and maps and such.

> By the way, there is a newsletter (LINKLETTER) that we send out to the
> regional networks and other interested parties. There have been ten issues
> or so so far. If you want to be added to the distribution, please send
> your request to nsfnet-linkletter-request@merit.edu
>
>     -- Hans-Werner

Yes, please add me to the distribution list.

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 88 13:10:43 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain name server on SUN 4-280 Help !!!

Unless you are using the latest (Release 16) of the UB code it
is NOT using domain name resolution.  Older UB TCP's use the
IEN116 name server, which sun calls in.tnamed.  This reads /etc/hosts.
I recompiled it on our machine so that it would call the domain version
of gethostbyname.  The UB's then came alive.  It's probably just easier
to get UB to send you Rel 16, because you can not make the older PC/NIU
software to work without substantial hacks to the tnamed anyway.

-Ron

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 88 14:36:17 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

grn@stl.stc.co.uk () writes:
> The type of question that I would expect to be able to answer given a
> specification is the use made out-of-band data in rlogin for example.

	I've been working on-and-off for a year or so trying to get my own
version of rlogin working under SunOS-3.2 and lately 3.5.2.  The stumbling
block has been the out-of-band data part.  Basicly, rlogin uses oob to
negotiate options such as "please inform me of window-size changes", but as
to the details of exactly how it works, I've had to just read the source
code (not a useful answer if you don't have source).  I sort of think I
might have most of it figured out, but not well enough that I would risk
inflicting my misconceptions on other people.

	Perhaps I've made my job harder than it has to be by trying to get
my rlogin to run as a suntools application.  I use the notifier to tell me
when oob data is available, but I don't think it works properly.
Sometimes, my oob routine gets called by the notifier (which supposedly
means there is oob data waiting to be read) but when I try to read it,
nothing is there (i.e. select says there is nothing pending, recv returns
0, ioctl says I'm not at the mark, etc).
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 88 20:57:45 GMT
From:      sw0l+@ANDREW.CMU.EDU ("Steven L. Waldbusser")
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP/SGMP/ASN.1 information request

I have an SGMP server (soon to be SNMP) that will be put in the public domain.
It is not yet in distribution form, so it isn't available via anonymous FTP.
Because of your time constraints, however, I can package everything up and send
it to you "as is".

This package includes the ASN builder and parser libraries, and the server code
that runs on the Kinetics Box (it also runs on CMU's PC/AT based gateways).
Some Unix/X based applications are also planned.

The documentation you are looking for is as follows:

RFC1028         SGMP
RFC1065         Structure of Management Information (SMI)
RFC1066         Management Information Base (MIB)
RFC1067         SNMP



Steve Waldbusser
Network Development
Carnegie-Mellon University

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 88 21:12:29 GMT
From:      yeongw@REBEL.NYSER.NET (Wengyik Yeong)
To:        comp.protocols.tcp-ip
Subject:   Re:  SNMP/SGMP/ASN.1 information request

idea011-01 has been superseded by RFC1067. You probably want to
look at RFC1065 and RFC1066 also, which deal with the information
that SNMP manages. To the best of my knowledge, ASN.1 is documented
only in the two ISO documents you cite, which are not available
from anonymous ftp but may be obtained from Omnicom Inc. (don't remember
the address and I'm at home right now).

As far as I know, there is no public domain version of SNMP available
today.

Good luck.....


Wengyik

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 88 22:11:15 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   Specification of Berkeley networking utilities

> Is there a public domain specification of the Berkeley networking
> utilities such as rlogin? 

Unfortunately, no; the source code itself, however, while not public
domain, is freely redistributable.  This includes inetd, ping, rcp,
rdist, rexecd, rlogin, rmt, route, rsh, rwho, rwhod, and talk among
other things.

Keith Bostic

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 00:47:02 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

Milo,

You are correct that ICMP and ARP et al should be part of a minimal
spec.  No arguments there...just the observation that getting
the right set of specs into a contract isn't very easy -- no cookbook
for TCP/IP.  The GOSIP effort is designed to head off some of
those problems.

Now, to DARPA's execution.  Making TCP/IP a trademark and requiring
certification certainly would handle a lot of your concerns, but
DARPA is an agancy for advanced research.  DCA should be doing
this kind of work at the production level, not DARPA.  Indeed,
they are doing some certification work and the horse is so far
out of the barn that trademarking TCP/IP is not fesible now.
Note that the Ada Joint Program Office (Ada, not ADA) is in the
office of the Secretary of Defense, not DARPA.

Rex Buddenberg

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Oct 88 08:00:07 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   err, SIGCOMM '89 Call for Papers

For those people who scan their subject lines before reading -- that
last announcement for SIGCOMM '88 should have been SIGCOMM '89.

Thanks and sorry for the goof,

Craig
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 01:22:50 GMT
From:      wrl@FORD-COS2.ARPA (Bill Lewandowski)
To:        comp.protocols.tcp-ip
Subject:   Internet Mail Addressing Question !!

I have a Mail Adressing Question I'm sure someone out there can help
me with:

Where can I find an explaination for the "%" (percent) character
as it is used in Internet Mail Addressing ?

I have gotten out RFC-821/822/733 and I can not see where the "%"
is a reserved or special character (It's not used in any examples in
either document). I know it's valid for sendmail but I have not
been able to find a reference yet.

I'm wondering if someone can point me to a document (RFC etc)
that covers the "%".

Any help would be appreciated.

Bill Lewandowski	Ford Aerospace Corporation
WRL@Ford-Cos2.arpa	Colorado Springs Division
(719) 594-1899

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 02:17:45 GMT
From:      barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Connected vs. Unconnected Nets

In article <12440301981.30.SUE@SRI-NIC.ARPA>, HOSTMASTER@SRI-NIC writes:

>One would not find any reference to network #3 there because it has
>unconnected status, although it is a legitimate number assigned to
>General Electric.

Yes. I posted the question about RPC broadcasts on network 3 because
we like to clean up our own problems first.

We are bringing up our new gateway soon.
-- 
Bruce

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 03:30:32 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Enough already - or - "The Further Adventures of Net 3"

OK, OK - I'm sorry already!

Net 3 is registered to GE.  They have every right to use that number!
I screwed up!

Now on the flip side - there are at least a dozen organizations who
have at one time or another picked their network numbers out of thin
air and at least 2 of these have eventually come on line on the
Internet.  One of these was a duplicate of a number already assigned -
small problem!  These are the ones I've know about - I have no idea
how many other random nets are out there lurking.

I can't stress enough the importance of getting your own private and
personal network number and not using such numbers as 127.x.x.x or the
number that SUN lists in its documentation.  So give me a break when I
(or someone else) questions the validity of a net number - the routing
space you save may be your own!

Mike

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Oct 88 09:50:49 EST
From:      Rob Hudson <SSROB%ECUVM1.BITNET@CUNYVM.CUNY.EDU>
Subject:   TCP-IP Information

  Hi,
    The Computing Center at East Carolina University is currently looking into
TCP-IP.  We would like to know some good books explaining TCP-IP and if there
are any documents on the Network that would be of help to us.  We are just
starting to look into TCP-IP so some of the material may need to be elementary.
                          Thanks in advance.


========================================================================
ROB L. HUDSON                                       SSROB@ECUVM1.BITNET
Systems Programmer                                  (919) 757 - 6401
East Carolina University                            Greenville, NC 27858


========================================================================
ROB L. HUDSON                                       SSROB@ECUVM1.BITNET
Systems Programmer                                  (919) 757 - 6401
East Carolina University                            Greenville, NC 27858
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 07:45:48 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip, wrl@FORD-COS2.ARPA
Subject:   Re: Internet Mail Addressing Question !!

Bill Lewandowski asks about the use of '%' in addresses.

I don't remember if/when '%' was mentioned as far as the RFCs are
concerned.  I am fairly certain it is not listed in the RFCs you
mentioned.

RFC822 doesn't mention '%' so I assume it is treated as a local
character.  In theory, a route-addr requires a host to be registered.
I am told that this is what made '%' popular.  People needed ways to
send mail to other networks, such as BITNET, where machines were not
registered.
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Oct 88 11:56:51 EDT
From:      David Matthews-Morgan <DMM%UGA.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   System V Name Service
I am interested in finding out if there is any version of System V 3.x
that supports Domain Name Servers. Please send reply to DMM@UGA.BITNET.
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Oct 88 13:01:01 CDT
From:      Shane Davis <SHANE%UTDALVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        CLSIB21!DAVE@BBN.COM
Subject:   Mistakes...
Friends, Enemies, Dissentors, Offended:

I made a mistake. In fact, I can think of 3 mistakes:

1. I mentioned my employer.
2. With the above, I failed to place a disclaimer.
3. (Most important) I failed to communicate my point

As for (1) and (2), it appears my supervisor is forgiving this once, though
we all have difficulty forgetting...hopefully the net will oblige me by
forgiving me as well. If you out there have more to enumerate, tell me via
direct mail as I have removed myself from all mailing lists for my own
protection, job security (what's left), etc, as well as UT-Dallas's, if the
world's opinion of it is indeed lowered as my supervisor claims (I don't
disagree that it is, I really don't know...). Now, for the record, I state
that my opinions do not necessarily reflect the opinions of the Univ. of
Texas at Dallas or the UT System and that just because you may think I am an
idiot do not hold it against my employers, the forementioned.

(3) has caused me problems many times other than on this occasion. I will only
make a short clarification, as by now I doubt too many of you really care to
hear it. My point was not that my view is "right" and Mr. Hansen's is not; nor
was my point that he has no right to speak his opinion. My point was that
I do not think the TCP/IP discussion list is the appropriate place for such
statements. It is true that had I shared his view, I probably would not have
flamed him for putting it on his closing; I would not have defended his
placement of it there if someone else had flamed him for it, though. This list
is supposed to be about TCP/IP and networking, not politics. That was what
I intended to get across and I obviously do not have the communication skills
I believe I once had (or perhaps "once believed I had"...would have to ask my
high school teachers to determine which is correct), as it is clear that I
failed miserably in making that point concisely. If majority opinion holds
that it is not inappropriate for such statements to be made on this list, so
be it...I know I am not one to talk about appropriateness right now anyway.
When one fouls up as often as I, he does learn to realize that after the fact,
though that is certainly not as good as catching the mistakes before anyone
else sees them.

Apologies are in order. Neither my supervisor, director nor employer has
suggested, requested or mandated this apology; in fact I have spoken with none
of the above since the time the mail message was sent. My contriteness over
this incident is sincere.

First, I apologize to my supervisor and UT-Dallas for damage I may have caused
to his or the university's reputation. He's done enough for me I certainly
have no reason to wrong him and I share his belief that this university is a
great place which is only going to become better.

Second, I apologize to the readers of the list. I have not read any of the
mail from the list I have received since Friday; thus, I do not know if
all of the flames are aimed at me or not. Regardless, the character of the list
has been altered for the worse temporarily by my note and I know that none of
us enjoy it or we would be on a politics/flames list (as I would more tactfully
have referred to the fictitious list I mentioned in my note). In the final
analysis I am more guilty than Mr. Hansen of degrading the content of the list.

Last, I apologize to Mr. Hansen for seemingly denying him his right to express
his opinion.

I stand that the TCP/IP list should not have politics injected into it but I
do affirm that my tone and diction and the way my statements were interpreted
were more offensive than Mr. Hansen's closing. I emphasize that my intent
was not to deny anyone his right to speak but merely to point out that forums
geared toward such expression exist and that I do not feel the TCP/IP list
is a place to make political statements.

This note may appear as much a defense as an apology, but I assure you my
motivations are not selfish and that I may be stupid but not stupid enough
to defend the fallacious argument that what I said (the way I phrased it) was
proper. This note is an apology and for no other reason would I write it.
Remember that the most important point always comes last...I disposed of
my technical faults first thing.

I know my apologies cannot erase damage done to anyone's attitude or reputation
but it is better than ignoring my mistake. If I'm lucky, when I do get back on
a list or two, I will not be remembered as the "liberal Communist atheist
punk" who sent that message, as many of your current impressions may resemble.
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Oct 88 12:05:16 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Barry Shein <bzs@bu-cs.BU.EDU>, tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP on the DR11
>If we tolerate innocuous remarks in net.signatures I'd say we have to
>tolerate comments we disagree with also, short of (perhaps)
>obscenities or commercialism which is not the issue here.

I certainly agree - "signatures" are easy enough to ignore, if you want to.

>Most so-called "pro-lifers" seem to believe a person has rights only
>up to the moment of birth.

Besides being untrue, that's as least as offensive as the original
signature!  Why don't we declare both sides even and get back to the
original purpose of this list?

Doug Nelson

These views are entirely my own, etc., etc.
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 12:00:07 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   err, SIGCOMM '89 Call for Papers


For those people who scan their subject lines before reading -- that
last announcement for SIGCOMM '88 should have been SIGCOMM '89.

Thanks and sorry for the goof,

Craig

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 12:41:52 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

In article <8810232211.AA18006@okeeffe.Berkeley.EDU>, bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) writes:
> > Is there a public domain specification of the Berkeley networking
> > utilities such as rlogin? 
> 
> Unfortunately, no; the source code itself, however, while not public
> domain, is freely redistributable.  This includes inetd, ping, rcp,
> rdist, rexecd, rlogin, rmt, route, rsh, rwho, rwhod, and talk among
> other things.

	Have these things been published to a place where we can FTP
	them?  If not they are not public domain.  What of the library
	routines they rely on?  Can they be FTP'ed?

> 
> Keith Bostic

					Rick Spanbauer
					SUNY/Stony Brook

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 13:56:09 GMT
From:      schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP/SGMP/ASN.1 information request


    
    I'm implementing an SNMP proxy server for some bridges and gateways
    that don't support SGMP or SNMP.  The first part of this project
    is for a class I'm taking this semester, so I'm on a short time
    schedule.

    Can anyone out there help me find any of the following,
    preferably via anonymous ftp?  I can spend some money,
    but it has to be a small amount for me to get it through
    the university system in a short period of time.  I can
    spend larger amounts for the longer-term project, as it's
    not so time constrained.

    1.  Any SNMP server/client code.
    2.  Any SGMP server/client code.
    3.  Any ASN.1 documentation, or conversion code.

Don't work on SGMP, SNMP is now the standard and is already
more widely accepted.  Your work would have a longer future
there.

    Also, any relevant documentation.  I have the following:

    idea0011-00.txt.1
    idea0011-01.txt.1

Pick up RFC-1065,1066,1067 which are the relevant documents,
these were all published in August.

    and I am aware of the existence of SGMP RFCs, though I haven't
    searched for them yet.  Is there another idea?  I thought I saw
    a reference to idea0011-02 at one point but I didn't see it
    at sri-nic.arpa. Also, does idea0011-01 supercede idea0011-00?
    Are the ASN.1 specs (ISO International standards 8824 and 8825)
    available via anonymous ftp, or can I call or mail someone to
    get them?  Is there a cost?  Does anyone have SNMP or SGMP
    packet descriptions or sample packets they could mail me?

    I'll be glad to package up what I find out and post it, if the
    contributor(s) ok it.

NYSERNet of course has an implementation of SNMP which we've
been shipping since August (and SGMP back in January).

Marty

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 14:50:49 GMT
From:      SSROB@ECUVM1.BITNET (Rob Hudson)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP Information


  Hi,
    The Computing Center at East Carolina University is currently looking into
TCP-IP.  We would like to know some good books explaining TCP-IP and if there
are any documents on the Network that would be of help to us.  We are just
starting to look into TCP-IP so some of the material may need to be elementary.
                          Thanks in advance.


========================================================================
ROB L. HUDSON                                       SSROB@ECUVM1.BITNET
Systems Programmer                                  (919) 757 - 6401
East Carolina University                            Greenville, NC 27858


========================================================================
ROB L. HUDSON                                       SSROB@ECUVM1.BITNET
Systems Programmer                                  (919) 757 - 6401
East Carolina University                            Greenville, NC 27858

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 15:30:30 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Mail Addressing Question !!

RFC 822 and SMTP and Internet mail in general doesn't know '%' from
any other character.  When you send mail there are essentially two
significant parts.  The stuff to the left of the '@' and the stuff
to the right of the '@'.  When you send mail to a remote machine
you interpret the stuff to the right as the machine to connect to and
pass to it the stuff on the left uninterpretted.

Now if a host wants to use this character for some internal use (either
it allows a mailbox name to contain that character, or it is used for
a separater), this makes no difference to SMTP or 822.  All it knows
is that you care dropping mail into a mailbox whose id is the stuff
to the left of the '@.'

Now some machines use % as a special separator (notably older attempts
at CSNET mail).  They will essentially throw away the '@' and what is
to the right and then turn the % into an '@' and attempt to resend the
mail.  Generally this was used to route mail to another host which is
not really on the newtork.  However, it is up to the recipient host to
make this distinction, and if a host decided that % in a name means to
send that mail to the lineprinter, it's free to make that interpretation.

-Ron

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 15:42:31 GMT
From:      jose@MCL.UNISYS.COM (Jose Rodriguez)
To:        comp.protocols.tcp-ip
Subject:   is there a need for class A addresses?



These few messages on GE's network address has triggered some thoughts
I have been holding since the Annapolis IETF meeting, basicly:

Is there a need for class A addresses?

I can think of two possible uses of such an address:

1) A very large comm subnet - with 2^24 hosts.
(Does such a network exist? Will future telephones be IP hosts?)

2) Subnetting, say used by an organization with 255 class B networks.
(Would such an organization exist? Could the gateways front-ending the 
subnetted network be able to handle the load?)

Your comments on the above will be appreciated.

Jose M. Rodriguez
Unisys McLean R&D

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 15:42:53 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   oob in rlogin

>>from grn@stl.stc.co.uk:
>>
>>Is there a public domain specification of the Berkeley networking
>>utilities such as rlogin? 
 
> Keith Bostic:
>
>Unfortunately, no; the source code itself, however, while not public
>domain, is freely redistributable.  This includes inetd, ping, rcp,
>rdist, rexecd, rlogin, rmt, route, rsh, rwho, rwhod, and talk among
>other things.

	To quote my friend Schultzy:
		"The source code is the ultimate documentation..."

	This isn't exactly the clearest source code, so I will make a humble
	attempt to explain what goes on (also benefiting those without it):

>>grn@stl.stc.co.uk: 
>>
>>The type of question that I would expect to be able to answer given a
>>specification is the use made out-of-band data in rlogin for example.

	OOB data is used to pass four flags to the client:

		#define	TIOCPKT_FLUSHWRITE	0x02
		#define	TIOCPKT_NOSTOP		0x10
		#define	TIOCPKT_DOSTOP		0x20
		#define	TIOCPKT_WINDOW		0x80
	
	Any others are ignored.  TIOCPKT_FLUSHWRITE does just that, the
	client flushes the terminal queues, and any data up to the OOB mark.
	TIOCPKT_WINDOW causes the client to signal its parent process of
	a window size change.  TIOCPKT_NOSTOP turns disables CBREAK, enables
	RAW, sets t_stopc and t_startc to -1.  TIOCPKT_DOSTOP reverses the
	effects of TIOCPKT_NOSTOP.  This assumes a knowledge of the Berkeley
	terminal driver.  The oob data is written and read as type char.

>phri!roy.hyu.edu
>
>	I've been working on-and-off for a year or so trying to get my own
>version of rlogin working under SunOS-3.2 and lately 3.5.2.  The stumbling
>block has been the out-of-band data part.
>
>	(text deleted)
>
>	Perhaps I've made my job harder than it has to be by trying to get
>my rlogin to run as a suntools application.  I use the notifier to tell me
>when oob data is available, but I don't think it works properly.
>Sometimes, my oob routine gets called by the notifier (which supposedly
>means there is oob data waiting to be read) but when I try to read it,
>nothing is there (i.e. select says there is nothing pending, recv returns
>0, ioctl says I'm not at the mark, etc).

	I would have to see the source code to make a determination about
	this, but it sounds like the evaluation is correct.  For the
	benefit of others: make sure that you read in the data up to the
	mark and store it for later, or throw it away.  It is possible
	that the oob data has not been sent because the process is blocked
	on output and the input buffer is full.

>>grn@stl.stc.co.uk: 
>>
>>A second and related question is why does the SunOS 4.0 implementation
>>of rlogin and rsh reject connections with client port numbers in the
>>range 0-512? My desire for specification of the interoperability
>>requirements of these networking utilities was partly prompted by the
>>failure of our local rlogin implementation to interwork with the new
>>Sun implementation.

	Low numbers are reserved for servers.  A client process
	shouldn't be down in this range.  Rlogind and rshd reject
	numbers below IPPORT_RESERVED/2 (512) just for good measure.
	Also they expect numbers between IPPORT_RESERVED/2 and
	IPPORT_RESERVED to guarantee the authenticity of the client.


Joel A. Mussman
jam@radc-lonex.arpa, jam@etn-wlv.eaton.com

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 15:56:51 GMT
From:      DMM@UGA.BITNET (David Matthews-Morgan)
To:        comp.protocols.tcp-ip
Subject:   System V Name Service

I am interested in finding out if there is any version of System V 3.x
that supports Domain Name Servers. Please send reply to DMM@UGA.BITNET.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 16:05:16 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on the DR11

>If we tolerate innocuous remarks in net.signatures I'd say we have to
>tolerate comments we disagree with also, short of (perhaps)
>obscenities or commercialism which is not the issue here.

I certainly agree - "signatures" are easy enough to ignore, if you want to.

>Most so-called "pro-lifers" seem to believe a person has rights only
>up to the moment of birth.

Besides being untrue, that's as least as offensive as the original
signature!  Why don't we declare both sides even and get back to the
original purpose of this list?

Doug Nelson

These views are entirely my own, etc., etc.

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 17:13:46 GMT
From:      bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Enough already - or - "The Further Adventures of Net 3"

In article <8810240330.AA18002@beast.DDN.MIL> stjohns@BEAST.DDN.MIL (Mike St. Johns) writes:
>I can't stress enough the importance of getting your own private and
>personal network number and not using such numbers as 127.x.x.x or
>the number that SUN lists in its documentation.

Amen.

One of the departments on campus was late converting to OSU's Class B
address scheme, staying with the numbers that Sun had so graciously
provided them for far longer than anyone else around had.  Of course,
their users complained to our operators that "I can get from our
department to yours, why are your machines so broken that I can't get
from your machines back to ours?"

I recently attended a Sun Educational Services class on the system
administrative differences when upgrading to SunOS 4.* from 3.*.  In
the discussion regarding network configurations, I couldn't convince
the instructor that she should encourage people to get a real number
and use it, right off the bat.  "But it's just a little company!"
"They'll be connected someday."  "But they can just change over if
they ever want to get connected!"  "By that time they'll have a lot
more than the few hosts you just sold them and it will be a real
hassle."  She wouldn't be persuaded, and I looked to the assembled
gathering like a voice crying in the wilderness.  Then there was the
issue of the frustration of people trying to pit a nameserver vs YP...

Mamas, don't let your children grow up to do like them folks done!  If
you're using IP, get your own network number from the start.  That's
why there's IP in the first place: so that you can talk to the entire
rest of the world.  Save yourself muchos headaches later on.
-=-
Zippy sez,								--Bob
Don't hit me!!  I'm in the Twilight Zone!!!

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 17:38:00 GMT
From:      mre@beatnix.UUCP (Mike Eisler)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question:  ping w/o icmp support?

>    In article <527@mks.UUCP: egisin@watmath.waterloo.edu (Eric Gisin) writes:
>    :In article <440@gonzo.UUCP:, daveb@gonzo.UUCP (Dave Brower) writes:
>    :: A number of the machines I use support only the tcp and udp protocols. 
>    
>    You mean they're in violation of the RFC's? :-( ICMP is an integral
>    part of IP, and  it's got to be in there. Presumably you mean there's
   ^^^^^^^^^^^^^^^^^^^
>    no user-accessible interface to ICMP services.

It's *got* to be in there? What will happen if I don't implement it?
Will the IP police come for me? Or will God send lighting my way?  I
once implemented a simple UDP and IP for an AT&T 3b15 that was to be
used as an NFS server for a LAN of NFS clients. It worked quite well
without ICMP. I agree that you probably wouldn't want this
implementation on a public network, but it served the customer's
limited purposes.

	-Mike Eisler
	(For the record, I did this before I came to ELXSI, and all of ELXSI's
		operating systems implement ICMP.)

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 17:58:44 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

In article <8810221819.AA10475@nsipo.arc.nasa.gov> 
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
>
>There are implementations out there that fail to support ICMP. [...]
>
 
>I personally know of several implementations which are broken in the
>above ways, but I'd probably get sued if I spoke up on the net.  
>							Milo


	I can practically guarantee that:
	a) those fingered vendors would fix their products
	b) you would get sued
What a shame.  The Host Req'ts RFC is a big step forward, even
contains an easily abused checklist (as all the authors will take
pains over the coming years to point out everytime they speak in
public :-), but there is no way anyone can actually *SAY* what their
research shows is true, ie vendor X is not in compliance with
paragraph 3.1.2.3. (Not without considerable risk.)

	Well, I shouldn't complain.  Just gives me an excuse to go to
a conference and have Milo tell me in person what a crock such and
such is.

	A year or so after the Host RFC, maybe we could share
LANalyzer (or your favorite Ethernet analyzer) programs that check all
the RFC points?  Let the LANalyzer do the talking!  Probably
impractical, but wouldn't be nice to plug a new box into a protocol
testing box and watch the red light and the green light?  (I know, I'm
lazy and no fun at all.)

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 18:01:01 GMT
From:      SHANE@UTDALVM1.BITNET (Shane Davis)
To:        comp.protocols.tcp-ip
Subject:   Mistakes...

Friends, Enemies, Dissentors, Offended:

I made a mistake. In fact, I can think of 3 mistakes:

1. I mentioned my employer.
2. With the above, I failed to place a disclaimer.
3. (Most important) I failed to communicate my point

As for (1) and (2), it appears my supervisor is forgiving this once, though
we all have difficulty forgetting...hopefully the net will oblige me by
forgiving me as well. If you out there have more to enumerate, tell me via
direct mail as I have removed myself from all mailing lists for my own
protection, job security (what's left), etc, as well as UT-Dallas's, if the
world's opinion of it is indeed lowered as my supervisor claims (I don't
disagree that it is, I really don't know...). Now, for the record, I state
that my opinions do not necessarily reflect the opinions of the Univ. of
Texas at Dallas or the UT System and that just because you may think I am an
idiot do not hold it against my employers, the forementioned.

(3) has caused me problems many times other than on this occasion. I will only
make a short clarification, as by now I doubt too many of you really care to
hear it. My point was not that my view is "right" and Mr. Hansen's is not; nor
was my point that he has no right to speak his opinion. My point was that
I do not think the TCP/IP discussion list is the appropriate place for such
statements. It is true that had I shared his view, I probably would not have
flamed him for putting it on his closing; I would not have defended his
placement of it there if someone else had flamed him for it, though. This list
is supposed to be about TCP/IP and networking, not politics. That was what
I intended to get across and I obviously do not have the communication skills
I believe I once had (or perhaps "once believed I had"...would have to ask my
high school teachers to determine which is correct), as it is clear that I
failed miserably in making that point concisely. If majority opinion holds
that it is not inappropriate for such statements to be made on this list, so
be it...I know I am not one to talk about appropriateness right now anyway.
When one fouls up as often as I, he does learn to realize that after the fact,
though that is certainly not as good as catching the mistakes before anyone
else sees them.

Apologies are in order. Neither my supervisor, director nor employer has
suggested, requested or mandated this apology; in fact I have spoken with none
of the above since the time the mail message was sent. My contriteness over
this incident is sincere.

First, I apologize to my supervisor and UT-Dallas for damage I may have caused
to his or the university's reputation. He's done enough for me I certainly
have no reason to wrong him and I share his belief that this university is a
great place which is only going to become better.

Second, I apologize to the readers of the list. I have not read any of the
mail from the list I have received since Friday; thus, I do not know if
all of the flames are aimed at me or not. Regardless, the character of the list
has been altered for the worse temporarily by my note and I know that none of
us enjoy it or we would be on a politics/flames list (as I would more tactfully
have referred to the fictitious list I mentioned in my note). In the final
analysis I am more guilty than Mr. Hansen of degrading the content of the list.

Last, I apologize to Mr. Hansen for seemingly denying him his right to express
his opinion.

I stand that the TCP/IP list should not have politics injected into it but I
do affirm that my tone and diction and the way my statements were interpreted
were more offensive than Mr. Hansen's closing. I emphasize that my intent
was not to deny anyone his right to speak but merely to point out that forums
geared toward such expression exist and that I do not feel the TCP/IP list
is a place to make political statements.

This note may appear as much a defense as an apology, but I assure you my
motivations are not selfish and that I may be stupid but not stupid enough
to defend the fallacious argument that what I said (the way I phrased it) was
proper. This note is an apology and for no other reason would I write it.
Remember that the most important point always comes last...I disposed of
my technical faults first thing.

I know my apologies cannot erase damage done to anyone's attitude or reputation
but it is better than ignoring my mistake. If I'm lucky, when I do get back on
a list or two, I will not be remembered as the "liberal Communist atheist
punk" who sent that message, as many of your current impressions may resemble.

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 18:39:24 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip terminal servers

The primary reasons for wanting rlogin in a terminal server are:
  - sending terminal type for hosts that don't yet support that
	via telnet (i.e. 4.2 based instead of 4.3 based)
  - better handling of ^S, ^O, etc.
Rlogin has as provision for toggling local handling of things like
^S.  When you enter emacs or something else where that is 
inappropriate, the host sends a message telling the terminal server
to stop handling those things locally.  Thus rlogin sessions tend
to feel more transparent than telnet sessions.  One can do better
with telnet than is normally done by implementing telnet sync
properly, but rlogin is still a bit more transparent.  And of course
more existing telnetd's don't generate telnet sync, so in practice
rlogin is a big win for sites that don't want to put up their
own telnetd.  I don't know whether this is a big deal or not, but
people who are very sensitive to how the terminal interface
behaves may think so.

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 19:55:20 GMT
From:      map@gaak.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   ftp option PASV


   Date: Tue, 18 Oct 88 13:55:17 EDT
   From: barns@gateway.mitre.org (Bill Barns)

   Joel:

   You are right, they are wrong, and TOPS-20 FTP does the right thing
   (at least about this, and assuming nobody broke it while I wasn't looking).
   I will leave it to you to try to think of a TOPS-20 host that might
   allow you to use anonymous FTP to get files whose names you more or
   less know already.......

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

If that's in fact the case XX.LCS.MIT.Edu [18.26.0.36] might be a good
machine to try.  Most of the RFC's should be available to anonymous
FTP as RFC:RFCnnn.TXT (where nnn is the 3 or 4 digit number), this
should be a useful test (and doesn't require you to go far beyond
SLUDGE for testing.

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Oct 88 20:02:43 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

In article <845@acer.stl.stc.co.uk> grn@stl.stc.co.uk () writes:
>Is there a public domain specification of the Berkeley networking
>utilities such as rlogin? 

<Chortle>  Berkeley?  Document their protocols?  It is to laugh!  (Or
maybe to cry...)
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Oct 88 20:06:15 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip terminal servers

In article <10591.8810211408@brahma.cs.hw.ac.uk> keith@tarantula.spider.co.UK (Keith Mitchell) writes:
>In any case, I have yet to see a Unix system with rlogin which does not
>support telnet too. Telnet also has the advantage of being an officially
>defined and well-documented protocol, which is more than can be said for
>rlogin.

One unfortunate problem is that Berkeley rlogin is definitely a better
implementation than Berkeley telnet.  If you compare sources, it's fairly
obvious that rlogind is probably derived from telnetd, but various fixes
and improvements in rlogind have not found their way back into telnetd.
At least, not in the Sun sources that we have (VAXen are a vanishing
breed around here and I don't have any convenient way to check out the
current Berkeley sources).
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 20:33:13 GMT
From:      van@HELIOS.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   4BSD TCP Ethernet Throughput

Many people have asked for the Ethernet throughput data I
showed at Interop so it's probably easier to post it:

These are some throughput results for an experimental version of
the 4BSD (Berkeley Unix) network code running on a couple of
different MC68020-based systems: Sun 3/60s (20MHz 68020 with AMD
LANCE Ethernet chip) and Sun 3/280s (25MHz 68020 with Intel
82586 Ethernet chip) [note again the tests were done with Sun
hardware but not Sun software -- I'm running 4.?BSD, not Sun
OS].  There are lots and lots of interesting things in the data
but the one thing that seems to have attracted people's
attention is the big difference in performance between the two
Ethernet chips.

The test measured task-to-task data throughput over a TCP
connection from a source (e.g., chargen) to a sink (e.g.,
discard).  The tests were done between 2am and 6am on a fairly
quiet Ethernet (~100Kb/s average background traffic).  The
packets were all maximum size (1538 bytes on the wire or 1460
bytes of user data per packet).  The free parameters for the
tests were the sender and receiver socket buffer sizes (which
control the amount of 'pipelining' possible between the sender,
wire and receiver).  Each buffer size was independently varied
from 1 to 17 packets in 1 packet steps.  Four tests were done at
each of the 289 combinations.  Each test transferred 8MB of data
then recorded the total time for the transfer and the send and
receive socket buffer sizes (8MB was chosen so that the worst
case error due to the system clock resolution was ~.1% -- 10ms
in 10sec).  The 1,156 tests per machine pair were done in random
order to prevent any effects from fixed patterns of resource
allocation.

In general, the maximum throughput was observed when the sender
buffer equaled the receiver buffer (the reason why is complicated
but has to do with collisions).  The following table gives the
task-to-task data throughput (in KBytes/sec) and throughput on
the wire (in MBits/sec) for (a) a 3/60 sending to a 3/60 and
(b) a 3/280 sending to a 3/60.

	_________________________________________________
	|              3/60 to 3/60   |  3/280 to 3/60   |
	|            (LANCE to LANCE) | (Intel to LANCE) |
	| socket                      |                  |
	| buffer     task to          | task to          |
	|  size       task      wire  |  task      wire  |
	|(packets)   (KB/s)    (Mb/s) | (KB/s)    (Mb/s) |
	|    1         384      3.4   |   337      3.0   |
	|    2         606      5.4   |   575      5.1   |
	|    3         690      6.1   |   595      5.3   |
	|    4         784      6.9   |   709      6.3   |
	|    5         866      7.7   |   712      6.3   |
	|    6         904      8.0   |   708      6.3   |
	|    7         946      8.4   |   710      6.3   |
	|    8         954      8.4   |   718      6.4   |
	|    9         974      8.6   |   715      6.3   |
	|   10         983      8.7   |   712      6.3   |
	|   11         995      8.8   |   714      6.3   |
	|   12        1001      8.9   |   715      6.3   |
	|_____________________________|__________________|

The theoretical maximum data throughput, after you take into
account all the protocol overheads, is 1,104 KB/s (this
task-to-task data rate would put 10Mb/s on the wire).  You can
see that the 3/60s get 91% of the the theoretical max.  The
3/280, although a much faster processor (the CPU performance is
really dominated by the speed of the memory system, not the
processor clock rate, and the memory system in the 3/280 is
almost twice the speed of the 3/60), gets only 65% of
theoretical max.

The low throughput of the 3/280 seems to be entirely due to the
Intel Ethernet chip: at around 6Mb/s, it saturates.  (I put the
board on an extender and watched the bus handshake lines on the
82586 to see if the chip or the Sun interface logic was pooping
out.  It was the chip -- it just stopped asking for data.  (The
CPU was loafing along with at least 35% idle time during all
these tests so it wasn't the limit).

[Just so you don't get confused:  Stuff above was measurements.
 Stuff below includes opinions and interpretation and should
 be viewed with appropriate suspicion.]

If you graph the above, you'll see a large notch in the Intel
data at 3 packets.  This is probably a clue to why it's dying:
TCP delivers one ack for every two data packets.  At a buffer
size of three packets, the collision rate increases dramatically
since the sender's third packet will collide with the receiver's
ack for the previous two packets (for buffer sizes of 1 and 2,
there are effectively no collisions).  My suspicion is that the
Intel is taking a long time to recover from collisions (remember
that you're 64 bytes into the packet when you find out you've
collided so the chip bus logic has to back up 64 bytes -- Intel
spent their silicon making the chip "programmable", I doubt they
invested as much as AMD in the bus interface).  This may or may
not be what's going on:  life is too short to spend debugging
Intel parts so I really don't care to investigate further.

The one annoyance in all this is that Sun puts the fast Ethernet
chip (the AMD LANCE) in their slow machines (3/50s and 3/60s)
and the slow Ethernet chip (Intel 82586) in their fast machines
(3/180s, 3/280s and Sun-4s, i.e., all their file servers).
[I've had to put delay loops in the Ethernet driver on the 3/50s
and 3/60s to slow them down enough for the 3/280 server to keep
up.]  Sun's not to blame for anything here:  It costs a lot
to design a new Ethernet interface; they had a design for the
3/180 board set (which was the basis of all the other VME
machines--the [34]/280 and [34]/110); and no market pressure to
change it.  If they hadn't ventured out in a new direction with
the 3/[56]0 -- the LANCE -- I probably would have thought
700KB/s was great Ethernet throughput (at least until I saw
Dave Boggs' DEC-Titan/Seeq-chip throughput data).

But I think Sun is overdue in offering a high-performance VME
Ethernet interface.  That may change though -- VME controllers
like the Interphase 4207 Eagle are starting to appear which
should either put pressure on Sun and/or offer a high
performance 3rd party alternative (I haven't actually tried an
Eagle yet but from the documentation it looks like they did a
lot of things right).  I'd sure like to take the delay loops out
of my LANCE driver...

 - Van

ps: I have data for Intel-to-Intel and LANCE-to-Intel as well as
    the Intel-to-LANCE I listed above.  Using an Intel chip on the
    receiver, the results are MUCH worse -- 420KB/s max.  I chose
    the data that put the 82586 in its very best light.

    I also have scope pictures taken at the transceivers during all
    these tests.  I'm sure there'll be a chorus of "so-and-so violates
    the Ethernet spec" but that's a lie -- NONE OF THESE CHIPS OR
    SYSTEMS VIOLATED THE ETHERNET SPEC IN ANY WAY, SHAPE OR FORM.
    I looked very carefully for violations and have the pictures to
    prove there were none.

    Finally, all of the above is Copyright (c) 1988 by Van Jacobson.
    If you want to reproduce any part of it in print, you damn well
    better ask me first -- I'm getting tired of being misquoted in
    trade rags.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 20:36:26 GMT
From:      dupuy@douglass.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

Here's an old message which may shed light on your problems:

Article 1996 of comp.protocols.tcp-ip:
Path: columbia!rutgers!lll-lcc!lll-tis!ptsfa!rtech!daveb
From: daveb@rtech.UUCP (Dave Brower)
Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip
Subject: OOB problems, wisdom anyone?
Message-ID: <1482@rtech.UUCP>
Date: 18 Dec 87 19:58:03 GMT
Reply-To: daveb@rtech.UUCP (Dave Brower)
Organization: Relational Technology Inc, Alameda CA
Lines: 44
Xref: columbia comp.unix.wizards:6073 comp.protocols.tcp-ip:1996

Some people here have been trying to use the OOB mechanism to send
"expedited data" between processes.  No one here is all that familiar
with using it, and they have run into some problems that make them want
to give up and turn to something else.

I'd appreciate hearing general thoughts about using the BSD oob
mechanism for IPC, and specific comments on the problems they report
below.  I will forward responses to the interested parties.

Thanks!
-dB

------- forwarded message describing OOB headaches.

1.  "Leapfrogging:" The fatal aspect of OOB data is that when two
socket sends for OOB data are issued in sequence before the first has
been read, the second send passes the first and is read out of
sequence by the recipient.  This is a gross violation of the stream
socket abstraction and makes the mechanism fundamentally unusable
except in the simplest and most restricted cases, not the situation
here.

2.  OOB receive loop: When an application has been notified of the
availability of OOB data and issues a receive for it, a subsequent
receive for normal data must be issued to "clear" the OOB notification
mechanism.  If instead a select requesting notification of OOB data is
issued without an intervening receive for normal data, the caller is
immediately notified of the availability of OOB data: the same data
just received.  This is at best a form of bizarre and undocumented
behavior; at worst a serious bug.

3.  The integer-character problem: The IOCTL system call to determine
whether one has reached the OOB data in the stream is documented to
return a character.  Several coding examples support this.  In fact,
an integer is returned.  It was necessary, after considerable grief,
to go to kernel source code to find that in fact an integer is
returned.  It is not known how many similar major documentation errors
exist.  Each could cause major delays, with time spent in fruitless
debugging.


-- 
"If it was easy, we'd hire someone cheaper than you to do it."
{amdahl, cbosgd, mtxinu, ptsfa, sun}!rtech!daveb daveb@rtech.uucp


-- 
inet: dupuy@columbia.edu
uucp: ...!rutgers!columbia!dupuy

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 88 23:38:48 GMT
From:      bzs@BU-CS.BU.EDU
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on the DR11


Obviously I made my remarks as sarcastic counterpoint.

	-Barry Shein

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 00:55:51 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: is there a need for class A addresses?

In retrospect, the division points between class A, B, and C networks
are in the wrong places (class C newtorks are too small, class A
newtorks are too large).  However, it made the numbers easy to read in
dotted syntax, and was not too bad for a shot in the dark...  The
current directions of networking seem to imply that class A was always
too big, but back then it might have been reasonable to expect that
AT&T, for example, would want use class A addresses for each of its
telephones...

Bill Westfield
cisco Systems.
-------

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 08:51:01 GMT
From:      whna@cgcha.uucp (Heinz Naef)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.unix.questions
Subject:   TCP/IP terminalservers and BREAK(/^C)

Assume a VT-100-type terminal accessing a UNIX host in the following ways:
(1) via a TCP/IP terminalserver networked with the target host
(2) via an asynchronous line interface integrated in the target host

There is a significant difference in how a BREAK (CTRL-C) condition is
handled:
In case (1) the terminalserver (3Com/Bridge LS/1, Cisco xSM) continues to
empty its buffer towards the terminal.
In case (2) the output to the terminal stops immediately.

On a UNIX system, try to cat /usr/dict/words with the two attachments
described above. In case (1) tens, hundreds of pages will be displayed
after hitting BREAK (or ^C), which is considered a problem of acceptance.

What is the reason of this different behavior? Would there be no way to
"rollback" the current buffer's worth of packets upon receiving a BREAK
and just flush the buffer?

Thanks in advance for any comments.

Regards,
Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.58, P.O.Box, CH-4002 Basel, Switzerland
UUCP: cgch!whna - Internet: whna%cgch.uucp@uunet.uu.net
BITNET: whna%cgch.uucp@cernvax.bitnet

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 12:27:05 GMT
From:      sbbur@CONNCOLL.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re:  PICK and TCP/IP


> Is anybody aware of an implementation of the PICK operating
> system that includes TCP/IP in any way ?

Prime Computer offers Prime INFORMATION, a pick-based environment which
runs on top of their PRIMOS operating system.  They also offer an
ethernet controller for their systems and support for user/server ftp
and server telnet.  Rumor has it that user telnet and SMTP support will
be included in PRIMOS Rev 22, due to be released later this year.

Scott Burdick                   BITNET:  sbbur@conncoll.bitnet
Connecticut College

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 13:16:17 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Enough already - or - "The Further Adventures of Net 3"

bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes:
> I recently attended a Sun Educational Services class [...] I couldn't
> convince the instructor that she should encourage people to get a real
> number and use it, right off the bat.

	Perhaps there should be a permanently assigned class-C bogon-net
number.  All the gateways would know to just drop any packet destined to or
from any host on bogon-net.  Machines would come out of the box configured
to be on bogon-net, and/or the setup documentation would suggest that if
you don't have a real number, just use this one (perhaps without specifying
that is it the bogon-net, so as not to scare people off).

	As long as you are not connected and have your own private ethernet
with a few hosts on it and no IP gateways, life is fine.  Once you connect
up, you have to change over to make the outside gateways talk to you, but
at least you limit the damage you do to yourself.  Much better to have a
gateway drop your bogonograms then to think you are somebody else.  Anybody
care to guess how many net 192.9.200's there are out there?  Also, if you
are a network administrator and you see a packet coming in from bogon-net,
you are instantly alerted that somebody new came on the net and didn't get
a real net number.  Much better than to trying to figure out why it
suddenly looks like somebody from Sun just plugged into your ethernet.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 15:28:21 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?


	
		A year or so after the Host RFC, maybe we could share
	LANalyzer (or your favorite Ethernet analyzer) programs that check all
	the RFC points?  Let the LANalyzer do the talking!  Probably
	impractical, but wouldn't be nice to plug a new box into a protocol
	testing box and watch the red light and the green light?  (I know, I'm
	lazy and no fun at all.)
	
Kent,

Your box is going to have several different shades of yellow lights on it,
shading between red and green.  It is not a simple world, as the 
Host Requirements Working Group has repeatedly rediscovered.

Bob Braden

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 16:30:56 GMT
From:      swb@DAINICHI.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip terminal servers

The telnet protocol being worked up in the IETF should be able to
benefit from experiences with telnet, rlogin, supdup and more, and
solve a bunch of these problems.

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 16:36:56 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Enough already - or - "The Further Adventures of Net 3"

In article <3567@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:

>at least you limit the damage you do to yourself.  Much better to have a
>gateway drop your bogonograms then to think you are somebody else.  Anybody
>-- 
>Roy Smith, System Administrator
>Public Health Research Institute

	I have not seen "bogonograms" before.  Has Dave Mills
authorized the use of this term?

	Kent England                [is :-) really needed here?]

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 17:07:57 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?


        I can practically guarantee that:
        a) those fingered vendors would fix their products
        b) you would get sued

This is silly.  I would dearly love to see some of our competitors
sue customers.  They'd never sell them a power cord after that.

There is no guarantee they'd fix the problem, either.

This sort of report has been done before, and published as a series
of RFCs.  The Smallberg surveys are summarized in RFC-847.  They
focussed on Telnet, FTP, and SMTP, but it was the same idea.

If you want to report this stuff, do it this way:

   state the CPU, OS, and release of the pinger and pingee,
   be prepared to repeat the configuration,
   make sure that the product is really advertised as TCP/IP,
   report it to the vendor at the same time you tell us.

If the information is true, you don't mis-represent the manufacturer,
and you do not have some other obligation (non-disclosure, procurement
regs), then nobody can complain.

The point about mis-representing the vendor is important.  If the
vendor doesn't claim that the product is TCP/IP, then they really
don't have an obligation to meet the specs.  It is still safe to point
out, "this is not advertised as TCP/IP, and sure enough, it doesn't
answer ICMP Echo."

An example of something that may use TCP, but isn't advertised as
such, is HP's OfficeShare for PCs.  It does disk and printer sharing
for PCs, with a PC or HP3000 server.  I suspect that it uses TCP/IP,
but it certianly isn't advertised as something that is supposed to
inter-operate with non-OfficeShare stuff.  I've never tried to ping
it, so I don't know if it supports ICMP Echo.

wunder

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 18:11:29 GMT
From:      raab@novavax.UUCP (Moshe Raab)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip information request

i am trying to gather information about tcp-ip. i have to devise a method
to allow file transfer and shared database between ibm 3081, 2 tandem computers
possibly a vax (vms) and local area networks.
i have heard about tcp-ip and it sounds like it may be just what the dr. 
ordered, but i don't know anything about how it works, what is involved in
setting a network etc.
i would appreciate any information, direction etc.
thank you very much

moshe raab

p.s. please reply to my private mailbox, if possible. thanx

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 19:20:45 GMT
From:      chet@pirate.CWRU.EDU (Chet Ramey)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

In article <1988Oct24.200243.19459@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <845@acer.stl.stc.co.uk> grn@stl.stc.co.uk () writes:
>>Is there a public domain specification of the Berkeley networking
>>utilities such as rlogin? 
>
><Chortle>  Berkeley?  Document their protocols?  It is to laugh!  (Or
>maybe to cry...)



Mike Karels said last year that he was avoiding making the `r-series'
protocol specs public (i.e.  documenting them) because he was lobbying
some people to add extensions to Telnet to do the stuff that rlogin does
(e.g.  pass the environment).  He said he hoped that if that stuff got
into Telnet, rlogin and friends could just fade away quietly without
proliferating. 

(Christ, Henry, don't you ever have anything nice to say about Berkeley?  Even
once? (Henry? Say something nice about Berkeley? It is to laugh! :-))

Chet Ramey


Chet Ramey            			chet@cwjcc.CWRU.EDU
Network Management Group		chet@alpha.CES.CWRU.EDU
Andrew R. Jennings Computing Center	chet@pirate.CWRU.EDU
Case Western Reserve University

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 19:34:37 GMT
From:      mo@prisma.UUCP
To:        comp.protocols.tcp-ip
Subject:   4.3BSD-Tahoe telnet

before castigating too loudly, check out the version
of telnet on the Tahoe tape.

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 19:46:39 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  oob in rlogin

Joel A. Mussman (jam@radc-lonex.arpa) notes:

>OOB data is used to pass four flags to the client:
>
>	#define	TIOCPKT_FLUSHWRITE	0x02
>	#define	TIOCPKT_NOSTOP		0x10
>	#define	TIOCPKT_DOSTOP		0x20
>	#define	TIOCPKT_WINDOW		0x80
>
>Any others are ignored.

This is true, but only because the others are hard to implement in
the current Berkeley system.  There are three more:

	#define	TIOCPKT_FLUSHREAD	0x01

This is intended to throw out typeahead.  Only that typeahead which
was present when the out of band data itself was sent should be discarded;
since there is no way to tell when that was, the current rlogin client
ignores this.

	#define	TIOCPKT_STOP		0x04	/* stop output */
	#define	TIOCPKT_START		0x08	/* start output */

Upon receiving a STOP, the client should stop copying output, and
should cause the local tty device to stop producing output, but *not*
stop receiving; the client should resume output (without dicarding
anything) upon receiving a START.  Servers should never send both STOP
and START in the same OOB data, but if it happens I suspect the proper
action is to resume if currently stopped, and otherwise to do nothing.

Stop and start ought to be unnecessary, but the DOSTOP/NOSTOP protocol
only accomodates ^S/^Q flow control.  Positive flow control (ENQ/ACK
and the like) does not need STOP and START, but negative flow control
using characters other than ^S/^Q will in fact generate STOP and START
requests.

Chris

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 20:13:43 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   telnet v.s. rlogin

>henry@zoo.toronto.edu writes:
>
>One unfortunate problem is that Berkeley rlogin is definitely a better
>implementation than Berkeley telnet.  If you compare sources, it's fairly
>obvious that rlogind is probably derived from telnetd, but various fixes
>and improvements in rlogind have not found their way back into telnetd.
>At least, not in the Sun sources that we have (VAXen are a vanishing
>breed around here and I don't have any convenient way to check out the
>current Berkeley sources).

The current Berkeley sources aren't that much different, though a fuller
implementation of the telnet features had been added with 4.3.

HOWEVER, the rlogin and telnet protocols differ in one major aspect (along
with a few minor ones...).  The design of telnet implies that data is
always sent in segments with a line terminator.  This is good with hardware
like IBM, but not good at all if you want to run software that peeks at
exactly what the keyboard is sending.  Rlogin is much simpler in nature,
and just passes whatever is typed at the keyboard.  You press <CR>, the
host software gets <CR>.  Telnet would translate that to an end-of-line
sequence, which is open to interpertation on the other end.

Almost a year ago there was discussion of adding a mode to telnet that
would handle a terminal like rlogin.  Sort of a RAW data mode without
the stipulations that telnet places on that mode.  This never came about.
Perhaps more people just took to using rlogin?

Joel A. Mussman
jam@radc-lonex.arpa

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 20:23:42 GMT
From:      joshua@athertn.Atherton.COM (Sleaze Hack)
To:        comp.protocols.tcp-ip
Subject:   Reliable Datagrams for RPC


I need to implement an RPC (remote procedure call) library, which will be
used as the basis for a commercial product.  RPCs will need to be made between
machines of different types, on client TCP/IP networks which we have little
control over.  I have a few questions:

1. What are the commercial RPC packages available?  I know about Sun's RPC,
Apollo's RPC, and Netwise's RPC, but are there others?

2. Assuming none of these fit my needs:
    (a) Does anyone have PD code which implements a reliable datagram
	service on top of UDP?  (Ideally, the packets would be of arbitrary
	size, also.)

    (b) Can anyone tell me where the algorithms for such a service have
	been published.  The closer the presentation is to C, the better.

    (c) I'm assuming that TCP is not the answer to my problem, since it
	is based on long lived connections.  Is this correct?

Answers to question 1 should be sent to me, and I'll summarize to the net.
I think discussion about question 2 is more general, and should take place
on the net.  Sorry if these issues have been discussed before.

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

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 20:38:03 GMT
From:      hrp@snoid.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   Specification of Berkeley networking utilities

According to Mike Karels, there are no plans to write specifications
for the protocols used by the r-commands because they were originally
hacks to try out TCP and should die a natural death.  If they were
documented, then people would be implementing them, they would
proliferate, and there would be no getting rid of them.  The party
line is that 4.3 telnet is better anyway, so we should all be using that.

[The information is from a the question and answer session at a
tutorial Mike Karels gave at the Monterey TCP/IP conference last year.]

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.cray.com@uc.msc.umn.edu	bungia!cray!hrp	    (612) 681-3145

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 20:41:19 GMT
From:      renglish@hpisod1.HP.COM (Robert English)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP

> / snorthc@RELAY-NSWC.NAVY.MIL /  4:49 am  Oct 19, 1988 /
 
> That however is the answer [ I think] to the question what is NetBIOS
> for.  Even just as a file service, it had potential.  What choked it
> for us was the memory required to make it work.  Why would anyone
> want transparent file access?  Sigh.  To this day, I wouldn't want
> to be held to this, but supposedly users do not want to be bothered
> to log in via FTP to xfer a file.  They want the file to be referenced
> as drive "F:".

Saying "users don't want to be bothered" trivializes the issue somewhat.
There are many DOS applications in which users never see the actual
files involved.  The application presents them with menus to perform
tasks, and manages the files itself.  A user who had to transfer all of
the necessary files over via FTP would have to be much more
sophisticated than one who merely used the application.

Furthermore, there is the issue of file-sharing.  If users access the
files on the remote machine directly, they can share effectively share
data with other users.  If they must copy the data back and forth, they
are likely to get inconsistent versions, forget to do the copies, etc.
(I know, you've never walked away from a terminal without writing out a
file).

Working in a non-transparent environment is significantly more
complicated than working in a transparent one.

--bob--

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 88 20:45:27 GMT
From:      hrp@snoid.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   Dumb question:  ping w/o icmp support?

Through the magic of IP, any machine that can attach to any LAN
anyware can suddenly talk to anything anywhere, and must be a good
citizen, expected to put up with delays and ICMPs and other
flakinesses that don't happen on the neighborhood Ethernet.  The
Internet old-timers have used up cases of analgesics trying to ease
the headaches caused by implementations that ``you probably wouldn't
want on a public network, but serve the customer's limited purposes.''
In some ways we would be far better off with IP police than we have
been without them (you can never find one when you need one).

				Hal
--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.cray.com@uc.msc.umn.edu	bungia!cray!hrp	    (612) 681-3145

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Oct 88 08:27:55 -0400
From:      Craig Partridge <craig@SH.CS.NET>
To:        phil@brl.mil
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Specification of Berkeley networking utilities


> Maybe once telnet can: ....  (2) handle remote window size changes

See RFC 1073

Craig
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 02:04:50 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Enough already - or - "The Further Adventures of Net 3"

In article <3567@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes:
> 	Perhaps there should be a permanently assigned class-C bogon-net
> number.  All the gateways would know to just drop any packet destined to or
> from any host on bogon-net.  Machines would come out of the box configured
> to be on bogon-net, and/or the setup documentation would suggest that if
> you don't have a real number, just use this one ...
> -- 
> Roy Smith, System Administrator
> Public Health Research Institute
> {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net

In the dark ages, SGI shipped machines with default host files naming a
brand new, out of the box machine as 'IRIS' on net 89.  As a result,
there are no doubt many network islands running with net #89 (or 49, but
that is a different though similar story).  Some time ago, in a fit of
embarrassment and remorse, I registered a class-C network for SGI to
serve exactly this purpose.  At that time, I petitioned the Gods for an
official solution.  In Their wisdom, though no doubt not because of my
unworthy request, They declared that host 192.0.2.1 on the official
test network should be used.

Since then, it has become fairly elaborate.  An IRIS comes named
'192.0.2.1 IRIS' on its disks, tapes, and even in NVRAM.  When the
PROM's, bootp (RFC-951) server, and various "system administration"
tools notice the bogus number, they complain or do something else
reasonable sounding.

If I misunderstood the Gods, I hope that someone will enlighten me.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Oct 88 09:16:43 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   how fast should TCP go?

Van Jacobson's recent note reminded me of a question I've been mulling
over on and off for a while:  Is there a simply way to estimate how
fast your TCP should be able to go on a given machine?

The question interests me because I'd like some way to figure out if
someone comes up to me and says "I've gotten the TCP on a Bozo-box
to run at 10mbits/sec" whether that's good or bad.  In other words,
given a few details of the Bozo-box architecture I'd like to be
able to make a rough estimate of how fast its TCP will go (without
having to resort to the micro-second analysis that Van and Dave
Borman are doing).  One advantage of such an estimate is that one
can spec a design and say "that should go at X bits/second."

The best approximation I've been able to come up with is the checksum.
Figure out how fast the box can checksum data and that's your maximum
speed.  Furthermore, if your network hardware and operating system are
any good you ought to get close to that value.  The logic is that all
other protocol operations are O(1) except for a memory copy that can
be done at the same time with the O(m) checksum (m is the message length).
The other nice thing about the checksum is that it is easy to compute
a rough guess at the maximum checksum speed -- its usually MIPS * word size.
(see RFC 1071 for adding with word sizes > 16-bits).  Some computers
don't follow this paradigm (the checksum on a Cray is vectorized and if
memory is slow, then the effective MIPS may be less than advertised) but
most come close, and it may be a handy rule of thumb.

Anyway, this idea has been knocking around in my head long enough I
thought I'd let it out and see if people want to beat me up for it.
(Happy to take blows if it gets us closer to a good way to approximate
the expected TCP performance).

Craig
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Oct 88 08:54:49 MDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        jolinec@sun.com
Cc:        Sun-Nets@brillig.umd.edu, tcp-ip@sri-nic.arpa
Subject:   RE: Sun Service Order 185504
Well, I just installed ypserv.68020 and ypxfr.68020 on my SUN-3 server.

The good news: the server rebooted.

The bad news: it still makes strange nameserver requests, which would
have caused the reboot to hang. (The non-printable fix is not there
either)  See attachment 2 for the kinds of weird requests from
this "patched ypserv and ypxfr".  Some of these will work because we
actually have hosts like "H.lanl.gov", not that we are really resolving
them.

I have a question for Sun.  Wouldn't it be a good idea to have an
"Internet" test bed for your product?  That, after all, is a good part
of your market.  And those who are not a part of the Internet wish they
were.  It is obvious that Internetting is not really part of your
focus (see attachment 1). What is?  OSI?  yuck, yuck.

For us, the Internet is the computer.

Phil Wood,   cpw@lanl.gov

P.S.  Your address: jolinec@sun.com indicates that you do use the Internet
on occasion!

ATTACHMENT 1 from Sun Fix 1011577, 1011370

"... 
 Problem description:

   YP link to resolver for name resolution does not seem to work.
   LITTLE DOCUMENTATION EXISTS TO SUPPORT THIS SETUP.  The
   makedbm -b option is SUPPOSEDLY necessary for interdomain
   name lookup. ..."  
   
   The CAPITALIZED words are for focus.,

ATTACHMENT 2

datagram from 128.165.112.128 port 1043, fd 5, len 28
req: nlookup($.lanl.gov) id 256 type=1
req: found '$.lanl.gov' as 'lanl.gov' (cname=0)
req: answer -> 128.165.112.128 7 (1043) id=1 Local
 
datagram from 128.165.112.128 port 1044, fd 5, len 28
req: nlookup($.lanl.gov) id 512 type=1
req: found '$.lanl.gov' as 'lanl.gov' (cname=0)
req: answer -> 128.165.112.128 7 (1044) id=2 Local
 
datagram from 128.165.112.128 port 53, fd 5, len 17
req: nlookup() id 256 type=2
req: found '' as '' (cname=0)
req: answer -> 128.165.112.128 7 (53) id=1 Local
 
datagram from 128.165.112.128 port 1045, fd 5, len 28
req: nlookup(r.lanl.gov) id 256 type=1
req: found 'r.lanl.gov' as 'lanl.gov' (cname=0)
req: answer -> 128.165.112.128 7 (1045) id=1 Local
 
 datagram from 128.165.112.128 port 1046, fd 5, len 28
req: nlookup(r.lanl.gov) id 512 type=1
req: found 'r.lanl.gov' as 'lanl.gov' (cname=0)
req: answer -> 128.165.112.128 7 (1046) id=2 Local

datagram from 128.165.112.128 port 1047, fd 5, len 28
req: nlookup(H.lanl.gov) id 256 type=1
req: found 'H.lanl.gov' as 'H.lanl.gov' (cname=0)
req: answer -> 128.165.112.128 7 (1047) id=1 Local

datagram from 128.165.112.128 port 1048, fd 5, len 28
req: nlookup(^D.lanl.gov) id 256 type=1
req: found '^D.lanl.gov' as 'lanl.gov' (cname=0)
req: answer -> 128.165.112.128 7 (1048) id=1 Local

datagram from 128.165.112.128 port 1049, fd 5, len 28
req: nlookup(^D.lanl.gov) id 512 type=1
req: found '^D.lanl.gov' as 'lanl.gov' (cname=0)
req: answer -> 128.165.112.128 7 (1049) id=2 Local



-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 02:55:39 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Enough already - or - "The Further Adventures of Net 3"

kwe@buit13.bu.edu (Kent England) writes:
> 	I have not seen "bogonograms" before.  Has Dave Mills
> authorized the use of this term?

	To the best of my knowledge, I made the term up.  Did I do
something wrong?  Should I write an RFC?
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 04:21:29 GMT
From:      phil@BRL.MIL (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  Specification of Berkeley networking utilities

> If they were documented, then people would be implementing them, they
> would proliferate, and there would be no getting rid of them.  The party
> line is that 4.3 telnet is better anyway, so we should all be using that.

Surely you jest!  Maybe once telnet can: (1) log you in without requiring
a password in a file, (2) handle remote window size changes, (3) handle
OOB data for (e.g.) SIGINT output flushing, and (4) have every machine
handle raw octet data correctly, then I'll believe you.  For RLOGIN.
Try to do RCP and RSH with Telnet ....

As for proliferation, in this building alone I've got Suns, SGIs, Vaxes,
Alliants, Goulds, and even a Cray that implements it.  Its too late for
them to die out.

- Phil

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 04:35:00 GMT
From:      dougg@hammer.TEK.COM (Doug Grote)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP test suites

We wish to conduct conformance testing of our TCP/IP implementation,
and as such, we would like to obtain an appropriate protocol test
suite.  In particular, we are interested in either SysV or BSD based
suites, but would entertain suggestions for suites of other flavors
as well.  Since it's possible that some of the test suites were
developed in-house to validate a specific implementation, we would
also like recommendations for those suites that are generally
accepted throughout the industry as proof of compliance.

Further, we would also welcome recommendations for independent sites
that conduct TCP/IP conformance testing.

Please e-mail replies to the address below.

Thank you.


Doug Grote
Tektronix, Inc., IDG/ITD
(ARPA)	dougg@hammer.GWD.TEK.COM
(UUCP)	{decvax,ihnp4,allegra,uw-beaver,...}!tektronix!hammer!dougg

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 12:27:55 GMT
From:      craig@SH.CS.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities



> Maybe once telnet can: ....  (2) handle remote window size changes

See RFC 1073

Craig

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 13:52:35 GMT
From:      zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

In article <211@cwjcc.CWRU.Edu> chet@pirate.UUCP (Chet Ramey) writes:
>some people to add extensions to Telnet to do the stuff that rlogin does
>(e.g.  pass the environment).  He said he hoped that if that stuff got

Don't forget the transparency.  Full 8 bit file transfers (like uucp 'g')
don't work over telnet).


-- 
Jon Zeeff      			Ann Arbor, MI
umix!b-tech!zeeff  		zeeff@b-tech.ann-arbor.mi.us

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Wed Oct 26 21:31:41 1988
From:      microsof!randyd@beaver.cs.washington.edu
To:        uw-beaver!tcp-ip@sri-nic.arpa
Subject:   bogonograms
Has anyone compiled a Dave Mills dictionary?

Bogonograms, fuzzballs, and craymonsters are too amusing to be forgotten
in the ether.

Randy-
microsoft!randyd@uw-beaver.cs.washington.edu

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 17:06:19 GMT
From:      ccruss@deneb.ucdavis.edu (0059;0000000000;230;9999;98;)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for IBMs?

I  have been requested to come up  with solutions to connect some campus 
IBM  machines to our campus TCP/IP network.  The models are a System 36, 
an 4181 and a 9370. The System 36 and the 9370 are currently stand-alone 
but  would perfer to connect to an ethernet. The 4381 is on an IBM Token 
Ring with a bunch of PCs, so the preference there is to do TCP/IP on the 
token  ring. I can connect the token ring to the campus network with a a 
Proteon router, but can the 4381 talk TCP/IP on the token ring? 

What  has been  done at  other sites?  I hear  that IBM has solutions to 
these  problems,  but  I  also  hear  the  the  solutions  are messy and 
expensive. 

The  location with  the token  ring would  also like  the PCs to use the 
campus  network. Has anyone written a IBM  token ring adapter (real IBM) 
driver for PD software like NCSA Telnet? 

Thanks,
Russ
                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services       BITNET:    RDHOBBY@UCDAVIS 
     Davis Ca 95616           UUCP:      ...!ucbvax!ucdavis!rdhobby 
     (916) 752-0236           INTERNET:  rdhobby@ucdavis.edu

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 17:45:24 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Enough already - or - "The Further Adventures of Net 3"

Roy,

I suppose I should respond. To be honest, I don't invent half the
fractured netspeak I'm kidded about - I usually see or hear something
quaintly apt floating in the swamps and feed it to the alligators. So
far as I know, I first heard "bogon" from the crew at U Maryland, but
who knows where it had been floating before that. As far as the Millspeak
contribution to the netspeak dictionary that can be documented, I do
claim PING (Packet InterNet Groper), the first documented occurance
of which passed my lips in 1980. The notion of alligators swimming in the
swamps was born about then and even before the famous line (was it
Alexander Haig) "When we are up to our ass in alligators, maybe we
should remember we're here to drain the swamp."

Posted on my wall is Pogo's famous line "We have met the enemy and he
is us." There are lots of other famous quotes there, too, from Scagliary,
Shakespeare, Churchill, Goethe and Vint Cerf.

Dave

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 18:47:42 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

> craig@sh.cs.net:
>
> Maybe once telnet can: ....  (2) handle remote window size changes
>
> See RFC 1073

Obviously I didn't catch up to this RFC.   I haven't seen much comment
on it through this forum, is the rest of the world in favor of it?
I know I am...

If so, as per the item I posted yesterday on rlogin v.s. telnet, is it
worth reopening the discussion of about a year ago, and doing an RFC
on the options to have better flow control and pass exactly the ASCII
representation of the key the user pressed?  On my systems the
interpretation of the end-of-line still causes whole bunches of headaches
with certain (allright, archaic) software packages that differentiate
between a <CR> and <LF>, and use both.

Joel

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 19:01:06 GMT
From:      SOL@SRI-NIC.ARPA (Sol Lederman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for PC

Marco,

The DDN NIC has a DDN Protocol Implementation and Vendors Guide which includes
information on a number of TCP/IP products for PCs and compatibles. The file
is available via FTP (host: sri-nic.arpa, user: anonymous, password: guest,
file: netinfo:vendors-guide.doc). If you cannot access an Internet host to do
the FTP then you can order a hardcopy version of the Guide for $40 (,$50 for
foreign orders). Contact NIC@SRI-NIC.ARPA for ordering information.

Sol/NIC

p.s. The Vendors Guide is large enough that SERVICE will not deliver it.
-------

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 20:31:12 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   "Reliable Datagram" is an Oxymoron


Josh:

The word combination "Reliable Datagram" is an Oxymoron.  By definition a
datagram can not be reliable.  See RFC-791 Section 1.

--jon.

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Oct 88 19:26:21 +0100
From:      psauly!mark@Sun.COM (marco graziano)
To:        oliveb!sun!tcp-ip%sri-nic.ARPA@Sun.COM
Subject:   TCP-IP for PC
I would like to know something about commercially available TCP-IP
packages for MS-DOS PCs.
Can anyone send me a list of them ?
Thanks.

Marco E. Graziano
Olivetti OS&N
Pisa - Italy
oliveb!psauly!mark@sun.com
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 21:08:21 GMT
From:      parker@waters.mpr.ca (Ross Parker)
To:        comp.protocols.tcp-ip,comp.dcom.modems,comp.dcom.lans
Subject:   Re: Wanted: SLIP oer 9600-baud modems -- Ultrix 2.x/4.3bsd

In article <6217@watcgl.waterloo.edu>, idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes:
> I managed to get SLIP working using direct-connected Trailblazer modems
> at 19200 bps between two VaxStation 2000 Ultrix 2.0 systems using some
> 4.3bsd SLIP source from the net, slightly modified to compile and fit
> into our Ultrix binary distribution.

I'd appreciate knowing what modifications you made to the SLIP source to
get things to work... I have slip compiling properly, but an slattach
produces the error message:

ioctl(TIOCSETD): No such device

Have I simply forgotten something in the kernel configuration, or does
the code need to be changed?

Thanks,

Ross Parker      uunet!ubc-cs!mpre!parker       |
Microtel Pacific Research Ltd.			| You can't erase the dream,
Burnaby, B.C.,					| you can only wake me up...
Canada, eh?					|

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 21:57:29 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Specification of Berkeley networking utilities


	
	Surely you jest!  Maybe once telnet can: (1) log you in without requiring
	a password in a file, (2) handle remote window size changes, (3) handle
	OOB data for (e.g.) SIGINT output flushing, and (4) have every machine
	handle raw octet data correctly, then I'll believe you. 
	
Phil,

   I believe that a properly implemented Telnet can handle all except (1)
   (note that RFC-1073 just got around to fixing (2)). Not everyone agrees
   that (1) is a good idea, although we obviously need a secure method
   to accomplish the same thing.

   It appears to me that the purported advantages of rlogin are due to
   poor Telnet implementations; do you disagree?
   
   Bob Braden
   

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 23:00:26 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   Re: tcp-ip terminal servers

In article <426@wasatch.UUCP> haas@wasatch.UUCP (Walt Haas) writes:
>
>> I know somebody on the net posts from Interlan ...
>
>It was interesting to note that there was no response from Micom/Interlan
>protesting that they try hard to give good service.  This is consistent
>with the way they don't answer phone calls.
>

	[]

	Keep those letters coming folks... We are now InterLAN, Inc;
	I have been feeding this sequence of postings to the new person
	in charge of support.  His name is Steve Young, I thhink you can
	reach him at this machine (young@interlan)

					Larry Backman

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 23:06:57 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re:  Specification of Berkeley networking utilities

In article <8810260021.aa23976@SPARK.BRL.MIL> phil@BRL.MIL (Phil Dykstra) writes:
>Surely you jest!  Maybe once telnet can: (1) log you in without requiring
>a password in a file, (2) handle remote window size changes, (3) handle
>OOB data for (e.g.) SIGINT output flushing, and (4) have every machine
>handle raw octet data correctly, then I'll believe you.

There's no reason why TELNET couldn't do all those things.  The TELNET
option mechanism provides nearly infinite expansion capability.

(1) A TELNET server that supports such a feature could send IAC DO
SEND-USERNAME (a new option I just made up) before sending the
"login:" prompt.  If the client supports this it will respond with IAC
WILL SEND-USERNAME and then uses the subnegotiation mechanism to send
the name.  The server would then bypass the normal login prompt and
log the user in, subject to access checks like those rlogin does.

(2) There are already standardized TELNET options for transmitting
line length and screen height.  Either these could be used or a new
window-size negotiation could be defined.

(3) TELNET already has this: IAC AO (Abort Output).  There is also an
IAC code for sending an interrupt.  Other OOB data could be
implemented using options.

(4) Again, this just needs a new option.  Actually, many
implementations interpret the TRANSMIT-BINARY negotiation as
specifying this.  This could be made official, or a new option could
be defined.

Yes, these things would require changes to TELNET implementations.
However, the effort to modify a TELNET implementation to support these
should be less than the effort to write an RLOGIN implementation from
scratch.  Of course, if you already have an RLOGIN implementation you
aren't going to be interested in modifying TELNET; even if you don't,
it's probably easier to port one than to extend TELNET.

The problem isn't that TELNET can't do what RLOGIN does, it's that
nobody bothered to define the necessary TELNET enhancements before
RLOGIN proliferated.  I think it's too late, and anyone who thinks
that RLOGIN can be phased out is dreaming.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 23:42:40 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet v.s. rlogin

>  The design of telnet implies that data is
>  always sent in segments with a line terminator.

I presume you're talking about go ahead.  That is almost never used.
When you're talking to a full-duplex host you negotiate it off.
Except for Braden's MVS implementation, even software for IBM hosts
doesn't do go aheads.  This option appears to be defunct.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 23:49:57 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip, zeeff@b-tech.ann-arbor.mi.us
Subject:   Re: Specification of Berkeley networking utilities

Telnet certainly can handle binary transfers.  It is quite possible that
the current implementations do not do it correctly, but the specification
certainly provides for it.  See RFC 856.
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 88 23:57:32 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.unix.questions
Subject:   Re: TCP/IP terminalservers and BREAK(/^C)

whna@cgcha.uucp (Heinz Naef) asks why ^C doesn't stop output when you
are logged into a system via a terminal server.  The most likely
answer is that one or more of your host or terminal server doesn't
implement telnet sync.  Output keeps coming because it has been
buffered.  In order to get good performance, data is aggregated into
1.5K segments.  Several KBytes of such segments may be sent at a time.
Meanwhile the terminal server is parcelling data out at a measly 9600
baud or whatever.  If the host stops sending stuff, the terminal
server may not get anything new, but there's this 10K or so of data
already in the pipeline (both on the terminal server and in the host).
There is a way to stop this.  What is supposed to happen is the
following: When a host wants to flush output, it sets the "urgent" bit
in the TCP headers.  This bit will be set in the next packet sent from
the host.  It takes effect on the terminal server as soon as such a
packet arrives.  It is not necessary to wait until the terminal server
gets to that packet in the course of dumping data to your terminal.
Its effect occurs "out of band."  As soon as the terminal server sees
a packet with this bit, it is supposed to stop output, throw away all
output in its buffers, and start ignoring new packets.  This continues
until it sees a special "sync" signal.  The sync is put into the data
stream where new data starts and output is supposed to resume.  If
both ends implement this properly, you will still get a bit of overrun
when you type ^C, because it does take some time for the ^C to get to
the host and the response to get back. But it will no longer go on for
pages.  I am reasonably sure that both the Bridge CS/1 and cisco ASM
implement this, so the problem is most likely in your host TCP/IP
implementation.  4.2 didn't do sync at all.  The initial 4.3 did it at
only one end (I think user telnet but not server, though I may have it
reversed).  I believe the latest 4.3 gets things right, but probably
most vendor implementations haven't updated to that release yet.
/usr/dict/words is a worst-case test, because it is very short lines.
So a delay of a couple of seconds can result in 10 pages going by.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 00:20:34 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

>Don't forget the transparency.  Full 8 bit file transfers (like uucp 'g')
>don't work over telnet).

We do UUCP and xmodem over telnet all the time.  Rutgers.edu is a
major UUCP hub.  All of its dialup UUCP transactions are done through
TCP/IP terminal servers.  (For reasons of efficiency on the host, we
are experimenting with having the terminal server go through a raw TCP
connection directly into uucpd.  However most connections still go
through telnet.)  For complete transparency, we require the user to
type "term download" on the terminal server.  This disables the
sequence that would otherwise get you back into command mode on the
terminal server (like ~ in rlogin), and makes a set of protocol
choices that provide an 8 bit transparent path with most of our server
telnet implementations.  You could do this by using telnet binary
mode.  However since binary mode doesn't always seem to work on Unix
telnet, we do it in normal mode simply by making sure that we choose
an end of line representation that is consistent with the one used by
the Unix server telnet.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 08:37:20 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        ssrob%ecuvm1.bitnet@NNSC.NSF.NET
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: TCP-IP Information

Rob:

    The consensus is that Doug Comer's book, Internetworking with TCP/IP
is the best one on TCP-IP.  It is available in most technical bookstores
(I've found it in every college bookstore I've been into in the past few
months).

    As for information about the Internet itself, there are several sources
of information.  Since I suspect you'll be connecting up to an NSFNET
regional network, I'll have an information packet sent out to you.

Craig Partridge
Director, Technical Services
NSF Network Service Center (NNSC)
(nnsc@nnsc.nsf.net)
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 02:44:26 GMT
From:      barnett@vdsvax (Bruce G. Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: is there a need for class A addresses?

In article <8810241542.AA07439@KAUAI.MCL.UNISYS.COM>, jose@MCL (Jose Rodriguez) writes:
>Is there a need for class A addresses?

Well, If you expect to have the number of machines a company like GE 
expects, there is some advantage to getting a single block of numbers
and assigning the network numbers from one organization.

Having dozens of divisions of GE requesting their own class C and B networks
seems much more inefficient. Especially when many sites have little experience
with the internet.

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 10:03:33 est
From:      eggers@dirac.cc.nd.edu (Mark D. Eggers)
To:        ccruss@deneb.ucdavis.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  TCP/IP for IBMs?
Russ,
     There are a variety of ways to connect your IBM PCs, 9370,
and 4381 to TCP/IP (sorry, don't know about the System 36). It
depends on what operating system you are running on the larger
boxes at to the solution. We use ACCES/MVS from ACC

720 Santa Barbara Street
Santa Barbara, CA 93101
(805) 963-9431

and have been quite satisfied with the results. Full screen access
to the IBM is provided either by tn3270 (from Berkeley or some
vendors, depending on the hardware) or SIMWARE running on the IBM (not
really nice, but survivable).

For VM systems, IBM's software seems to be quite nice. We don't run it,
but a researcher in our EE department (Dave Cohn, DLC@IRISHVM, BITNET)
does, and he seems quite happy with it. I have heard nothing but horror
stories about KNET, although you could check the KNET mailing list
about this. I have no experience with either package.

For PCs, the best software that I have seen is FTP's PCIP. 

FTP Software, Inc.
P.O.Box 150 Kendall Square Branch
Boston, MA 02142
(617) 868-4878

It has all the bells and whistles, and supports the widest array
of PC cards. It costs about $400.00 per PC.

If you need more information, just send email.

Standard disclaimer - The University of Notre Dame would prefer
	it if I didn't exist, and I am not a salesperson for
	any of the above mentioned software. I just use two out
	of three daily.

/mde/
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 05:46:27 GMT
From:      wcs@alice.UUCP (Bill Stewart, usually)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Multicast protocols

I have an application that wants to deliver the same data reliably
to a bunch of locations at once, where "bunch" is large enough that
using N ftp's at once is impractical.  Are there any standard
references to broadcast-oriented protocols?  I assume this has been
done before; getting acks back without collision storms should be
non-trivial, so I'd rather not re-invent.
		Thanks;
-- 
#				Thanks;
# Bill Stewart, att!ho95c!wcs, AT&T Bell Labs Holmdel NJ 1-201-949-0705
# and/or
# Shelley Rosenbaum, att!ho95c!slr, 1-201-949-3615   ho95c.att.com

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 06:22:53 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip,comp.unix.aux
Subject:   Re: tcp-ip terminal servers

Couldn't let be mention of the NTS100 TELNET / rlogin SERVERS.  They do when
the rep finally gets you the current ROM pack.  Then the puke from the factory 
says you have to return it or pay for it again .. sure come see me .. and the 
company attorney .. It works for me with modem inbound .. not so well but use-
able for outbound .. not UUCP.  We have been pretty stable for nearly a year.

For outbound services you want only one service class per server as best I can 
tell.  They take some getting used to.  Think I would prefer to LAT from a 
DEC Server to a telnet capable VAX if dollars weren't binding condition.

MY QUESTION.  We are on a site with a 192... address assigned.  That is across
a MILnet gateway.  To use my telnet / rlogin servers, must I consume some of
those 254 addresses?  Is there a network legal way to be on another net number
in the 255.255.255. upper 24 bits?  Which my local hosts can see and still
get helped NS from my local domain internal name server?

WHAT does every one else with multiple hosts and servers on a local ethernet
gatewayed to ARPA / Internet do to preserve host addresses with servers?  Do
your servers telnet to folks across the gateway?  We are still a way from
connected and I would appreciate some planning help .. thanks /Ev/
-- 
           The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
    efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 13:18:46 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   SUN RPC + bind = millions of datagrams

Hi folks:

    Some of you may have encountered a phenomena where a SUN system
blasts away your domain nameserver with thousands or even millions (yes
it's been observed) of domain queries.

    I know of at least three such cases on the Internet in the past two
weeks.  In all three cases a host at one end of the Internet was blasting
a nameserver at the other end (when NSFNET was in the middle of one of
these experiences the backbone traffic jumped by a factor of 2).

    The problem appears to be with using SUN RPC to resolve domain
names.  SUN RPC has no "soft error" mode, so if the server doesn't reply,
it just keeps asking -- forever.  If this happens in telnet or ftp,
that's OK -- the user will kill the program (and thus the RPC call)
eventually.  But if it happens in your SMTP or TELNET daemon, well,
you (and the net) have a problem.

    The fix appears to be to replace the SUN-provided gethostbyXXXX routines
in your shared libc with the domain versions.  SUN Customer Support can
apparently provide you with such a "fixed" libc.

Craig

PS: Many thanks to the folks at SUN who helped me get this information.
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 14:02:52 PDT
From:      postel@venera.isi.edu
To:        voder!pyramid!athertn!joshua@ucbvax.berkeley.edu
Cc:        TCP-IP@sri-nic.arpa
Subject:   RPC over UDP, etc.
Josh:

In addition to TCP, there are quite a few protocols defined over IP
(raw datagrams) and over UDP (user datagrams) that do provide reliable
information delivery.

For example see:

VMTP        RFC-1045
NETBLT      RFC-998
IRTP        RFC-938
RDP         RFC-908

DOMAINS     RFC-1034
TFTP        RFC-783

In addition, TCP may still be the answer, since it has been pretty well
tested and tweeked by now (and we are still learning things), why go through
that with a new protocol?

--jon.

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 15:17:25 PDT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        barmar@think.com, mckee@mitre.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Specification of Berkeley networking utilities
Shoot, you've forgotten the DoDIIS NVDET (Network Virtual Data Entry Terminal)
which is similar to TELNET NVT (Network Virtual Terminal) except a few of the
default assumptions are inverted and there are additional commands for cursor
positioning on a CRT display.
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 13:43:00 EDT
From:      <yurcik@lcp.nrl.navy.mil>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        yurcik
Subject:   Capital-area Meeting to discuss Network Security
TCP-IP Implementers in the area might be interested in attending
this meeting.  



*******************************************************************************
   The George Mason University School of Information Technology and Engineering
            and the Virginia Cooperative Graduate Engineering Program
   
                                     present
   
         Professional Development from the University of Maryland and the
       Washington D. C. Chapter of the Association for Computing Machinery
   
                 RECENT DEVELOPMENTS IN COMPUTER NETWORK SECURITY
   
                      An Interactive Televised Short Course
              Wednesday, November 9, 1988; 11:00 A. M. to 5:00 P. M.
   
Intended audience: The course is designed for senior technical managers in 
                   data processing, information systems and network 
                   environments in user organizations; senior development 
                   staff in hardware and software; manufacturer and supplier 
                   organizations; and consultants involved in OSI planning and 
                   implementations. 
   
Description:       This six-hour course presents an overview of recent 
                   developments in network security, emphasizing the Open 
                   System Interconnection (OSI) security architecture 
                   developed by the International Standards Organization and 
                   the Trusted Network Interpretation (TNI) developed 
                   by the National Computer Security Center.
   
                            *  Introduction to access control and authentication
                            *  Using encryption for authentication
                            *  Mandatory and discretionary access control
   
Location:      George Mason University; Science and Technology Building
               Rooms 110 and 112
               Parking is available in Lot B or in the Patriot Center Lot.
               Please stop at an Information Booth for a parking permit.
   
Registration:  Reservations are requested prior to Friday, November 4.  
   
To register please contact:  Mrs. Kathleen Jones
                             Cooperative Graduate Engineering Program
                             George Mason University
                             101 Science and Technology Building
                             Fairfax, VA 22030
                             323-3194


-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 09:54:54 CET
From:      Michael Nittmann <ZREN%DS0RUS1I.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   "Reliable Datagrams"

some hints on reliability: if it is not reliable, is it, then,

        non-reliable           or         unreliable?

This is the question here  I think since if you know what something is NOT
you have to state what is IS (at least in my positive attitude).


Of course an IP datagram is nor unreliable sice it has a checksum (this
IP header-checksum construct) and we can decide whether it's contents are
correct or not.
It is non-reliable since we cannot rely on it's delivery. There is no ack.

So I conclude that the IP datagram mechanism is a very reliable method to
deliver datagrams in a non-reliable fassion.

michael (and, all disclaimers of course.)

*******************************************************************
     Address:                              Local Office:

 CRAY RESEARCH GmbH                   CRAY SOFTWARE OFFICE
  Michael Nittmann                      Michael Nittmann
 Networking Support                  c/o
                                              RUS
 KISTLERHOFSTR. 168                  UNIVERSITY OF STUTTGART
    8 MUNICH 71                          ALLMANDRING 30
     GERMANY                              7 STUTTGART 1
                                            GERMANY
 E-mail and reply to:                      Phone:
 UG051%CRAYAMID.CRAY.COM@UMN-REI-UC.ARPA   0711/6855847 or 0711/6874767
*******************************************************************
Acknowledge-To: <ZREN@DS0RUS1I>
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 14:59:22 EDT
From:      hedrick@aramis.rutgers.edu (Charles Hedrick)
To:        jam@radc-lonex.arpa, tcp-ip@sri-nic.arpa
Subject:   Re: telnet v.s. rlogin
I certainly don't read the telnet spec's as requiring any kind of line
structure (aside from the GA stuff, which based on recent
correspondence is now officially dead).  As far as I can tell, end of
line is treated specially because the protocol designers thought that
some host might have line structure, and might need to make a
distinction between CR and EOL.  However as far as I know few if any
systems actually make this distinction.  (Many systems represent end
of line in files in different ways, but that's not the issue.  The
issue is whether what comes from the terminal when the user wants to
generate an end of line is CR.)  Thus I suspect this distinction is
about to become defunct, as GA apparently has.  The host requirements
draft implies that CR LF and CR NUL are to be treate the same, and are
to have the effect of the user typing CR.  In that case the special
role of CR more or less vanishes.  CR just gets translated to CR LF or
CR NUL and back again as a historical artifact.  It becomes a concern
only to implementors, like IAC doubling.  I hadn't noticed the RFC for
a negotiation to control whether CR is sent as CR LF or CR NUL.
However on a system where CR is end of line, CR LF and CR NUL are
going to be treated the same, and it is hard to see why the telnet
server would care which one is used.  So I don't see any reason for
the server to implement this option.  The user end would only be done
if it turned out that some other system actually needed it.

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 11:16:54 GMT
From:      gregb@dowjone.UUCP (Greg_Baber)
To:        comp.protocols.tcp-ip
Subject:   SNIFFER vs. Lanalyzer

I posted this several days on comp.dcom.lans. Upon reflection,
I thought that tcp-ip might help too, so here goes:

	Hello,
	My company is about to purchase an ethernet protocol analyzer and has narrowed
	the choice down to two machines, THE SNIFFER from Network General and The
	LanAlyzer from Excelan. Anyone who has used either of these two devices and
	has anything either good or bad to say about them, I'd appreciate it. We're
	interested in things like packet capture rate, completeness of protocol
	interpretation, and ease of use. If anyone has done a study similar to ours,
	please do not hesitate to call or email. Please, no salesmen, we're not look-
	ing for hype.                        Thanks, gregb

-- 
Reply to: Gregory S. Baber		Voice:	(609) 520-5077
	  Dow Jones & Co., Inc.		E-mail:	..princeton!dowjone!gregb
	  Box 300                           or  ..uunet!dowjone!gregb
	  Princeton, New Jersey 08543-0300

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 12:37:20 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP-IP Information


Rob:

    The consensus is that Doug Comer's book, Internetworking with TCP/IP
is the best one on TCP-IP.  It is available in most technical bookstores
(I've found it in every college bookstore I've been into in the past few
months).

    As for information about the Internet itself, there are several sources
of information.  Since I suspect you'll be connecting up to an NSFNET
regional network, I'll have an information packet sent out to you.

Craig Partridge
Director, Technical Services
NSF Network Service Center (NNSC)
(nnsc@nnsc.nsf.net)

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 16:44:35 edt
From:      stjohns@beast.DDN.MIL (Mike St. Johns)
To:        barmar@think.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Specification of Berkeley networking utilities
Umm - suprise - there already is a TELNET option to do "double login
avoidance".  It was invented by BBN to support extensions to the
TACACS system for DARPA.  The way it works is that each user name has
a unique id associated with it.  The TAC (or host I guess) does a "DO
DLA <id>" and gets back a WILL or WON'T.  Obviously this is full of
security holes.

Mike
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 18:06:29 CDT
From:      "Stuart Levy" <slevy@uc.msc.umn.edu>
To:        jam@radc-lonex.ARPA, mcvax!cernvax!cgch!cgcha!whna@uunet.uu.net, tcp-ip@sri-nic.ARPA
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)
Joel, you don't need to be nearly so discouraging.  There are mechanisms
for flushing telnet output, and several implementations already use them.

The Telnet RFC itself (854) describes a SYNCH mechanism for flushing
a buffered stream in either direction, using the TCP urgent-data feature.
Briefly, the sender sends an IAC DATAMARK command as urgent data;
the receiver, on noticing that urgent data has arrived, starts discarding
up to the (latest) urgent IAC DM.

The big advantage to this kind of open-loop flush is that the user telnet
(terminal server) need not even know what conditions should cause a flush.
If most of the buffering happens in the receiver as opposed to the network,
it can work pretty well.

It's also possible to do a closed-loop flush, which does an even better job.
In this case the user telnet must know that e.g. a BREAK or special character
should cause flushing.  It sends the interrupt or whatever command,
followed by IAC DO TIMING-MARK, and begins discarding received data.
The host eventually sees the TIMING-MARK and replies with IAC WILL (or WONT)
TIMING-MARK at (approximately) the right place in the data stream.
When the user telnet sees the reply timing mark, it resumes output.
This arrangement works even if the host telnet doesn't care about
output flushing; the TIMING-MARK reply is required by the Telnet spec.
Berkeley 4.3 telnet, and (at least) Bridge Communications terminal servers,
already use this style of flush if asked.

As for letting user telnets know what characters (^C, ^O, ...)
the host considers special, there's an IETF working group led by
Dave Borman of Cray Research which is designing a telnet option to do just
that among other things.  The present scheme doesn't actually provide
a way to say whether various functions should cause output flushing,
though I'm hoping that feature will make its way into the final RFC.

	Stuart Levy, Minnesota Supercomputer Center
	slevy@uc.msc.umn.edu
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 13:49:42 GMT
From:      ZREN@DS0RUS1I.BITNET (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   "Reliable Datagrams"


some hints on reliability: if it is not reliable, is it, then,

        non-reliable           or         unreliable?

This is the question here  I think since if you know what something is NOT
you have to state what is IS (at least in my positive attitude).


Of course an IP datagram is nor unreliable sice it has a checksum (this
IP header-checksum construct) and we can decide whether it's contents are
correct or not.
It is non-reliable since we cannot rely on it's delivery. There is no ack.

So I conclude that the IP datagram mechanism is a very reliable method to
deliver datagrams in a non-reliable fassion.

michael (and, all disclaimers of course.)

*******************************************************************
     Address:                              Local Office:

 CRAY RESEARCH GmbH                   CRAY SOFTWARE OFFICE
  Michael Nittmann                      Michael Nittmann
 Networking Support                  c/o
                                              RUS
 KISTLERHOFSTR. 168                  UNIVERSITY OF STUTTGART
    8 MUNICH 71                          ALLMANDRING 30
     GERMANY                              7 STUTTGART 1
                                            GERMANY
 E-mail and reply to:                      Phone:
 UG051%CRAYAMID.CRAY.COM@UMN-REI-UC.ARPA   0711/6855847 or 0711/6874767
*******************************************************************
Acknowledge-To: <ZREN@DS0RUS1I>

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 13:50:37 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)

> From: mcvax!cernvax!cgch!cgcha!whna@uunet.uu.net  (Heinz Naef)
> 
> Assume a VT-100-type terminal accessing a UNIX host in the following ways:
> (1) via a TCP/IP terminalserver networked with the target host
> (2) via an asynchronous line interface integrated in the target host
> 
> There is a significant difference in how a BREAK (CTRL-C) condition is
> handled:
> In case (1) the terminalserver (3Com/Bridge LS/1, Cisco xSM) continues to
> empty its buffer towards the terminal.
> In case (2) the output to the terminal stops immediately.
> 
> On a UNIX system, try to cat /usr/dict/words with the two attachments
> described above. In case (1) tens, hundreds of pages will be displayed
> after hitting BREAK (or ^C), which is considered a problem of acceptance.
> 
> What is the reason of this different behavior? Would there be no way to
> "rollback" the current buffer's worth of packets upon receiving a BREAK
> and just flush the buffer?

	This is something that probably you will never see fixed.
	On an async line the ^C gets back to the host almost at
	once.  On slow lines you can sometimes see a few extra
	characters pumped out before everything stops.

	Terminal servers use telnet (in most cases) to handle the
	connection to the host computer.  Since the data is flowing
	over the network a lot more of it can be queued up in packets
	while your ^C is trying to get back to the host.  The telnet
	protocol does not explicitly recognize ^C, and has no
	mechanisim for flushing following incomming packets after
	it is typed.

	But think about this:

	What if the user changed the interrupt character?  The protocol
	would have to be informed of the character change.  Also, special
	characters (like ^C) often depend on the operating system.  What
	types of special characters exist for different systems might
	make telnet a nightmare!

	But more important, if telnet would start flushing packets after
	it saw a ^C, what would tell it to stop?  Now the telnetd on
	the host would have to notice the interrupt, and send some kind
	of trailing sequence to the the remote telnet to stop flushing.

	I'm not saying it can't be done.  In fact, it might be a good
	idea (re: the rlogin v.s. telent discussion).  But it probably
	won't be anytime in the near future.


Sorry to be discouraging!
Joel

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 18:03:43 EDT
From:      Thomas M. Talpey <xpiinc!tmt@uunet.UU.NET>
To:        tcp-ip@uunet.UU.NET
Subject:   Re: Enough already - or - "The Further Adventures of Net 3"
> Perhaps there should be a permanently assigned class-C bogon-net number.
> All the gateways would know to just drop any packet destined to or
> from any host on bogon-net.

Why not assign it to the University of Mars and notify Dave Mills' famous
filters? Sounds like a good idea to me...

Tom Talpey
Xpi Inc.
tmt@xpiinc.uu.net
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 16:08:04 GMT
From:      retrac@RICE.EDU (John Carter)
To:        comp.protocols.tcp-ip
Subject:   Re: 4BSD TCP Ethernet Throughput

Van,

    I've made similar measurements on the similar machines, and come to
roughty the same conclusions.  My measurements are in the context of
the V operating systems interkernel protocols, but for raw hardware speed
comparisons, this shouldn't matter.

    Between two SUN-3/50 or SUN-3/60's (both with the LANCE interface),
I can sustain about 8.2 Mbps user-to-user performance (not source/chargen,
sink/discard).  From a SUN-3/180 (somewhat slower than the 2/180, but
with the same Intel ethernet interface) to a SUN-3/60, I can sustain
slightly more than 6.0 Mbps user-to-user performance.  All these
measurements are for 1024 byte data packets, with 80 byte V interkernel
headers (ouch!!!) and 14 byte ethernet headers.  Factoring the headers
in, the SUN-3/50 -> SUN-3/50 throughput is 9.0 Mbps and SUN-3/180 ->
SUN-3/50 throughput is 6.5 Mbps.  Roughly the same raw numbers...

    The SUN-2/50's (which use the Intel interface, but are significantly
slower) can maintain around 4.7-5.1 Mbps in or out.  These are very rough,
since I haven't fully debugged the implementation on the 2's.

    [ The following is opinion and shouldn't be construed as gospel. ]

    I also have only put a little bit of effort into determining the exact
cause of the disparity.  I had made the same decision you had regarding
the 82586's DMA ability, namely, it isn't very good (and can only sustain
60-70% of the network performance).  You conjectured that the interface
takes a long time to recover from interruptions.  I hadn't seen too many
collisions, so I hadn't thought of that, but it seems to fit with
some other observations I've made concerning the interface.  The Intel
interface tends to drop packets reasonably frequently when receiving large
packet bursts (blasts), presumably because of its inability to DMA in to
memory fast enough.  Another problem I have had, which seems to be caused
by the interface, is that it takes a relatively long time for the
interface to interrupt the processor when an event occurs (either a packet
reception completing, or a transmission completing).  An annoying
"feature" of the interface is the fact that you can't have receive buffers
start on odd boundaries (I suppose that they wanted to simplify the DMA
design).

    Finally, despite the great effort put in to designing a "programmable"
interface, I don't really think it was much easier to get to do what we
needed than the LANCE was.  True, it has a few less annoying
programmability problems (e.g., a less obscure method of selectively
accepting multicast packets, and the decision to not append the useless
harldware CRC to the end of each packet, thus requiring its handling
[which is particularly painful for optimistic blast, because I don't want
it to get redirected in to user memory, sigh]), but the overall decline in
raw performance overshadows these issues.  Heck, you only have to program
the thing once, performance lives forever (and is what counts)!

John

[And for anyone out there reading the cc'd copy of this, I'd like to add
 my voice to the call for a better ethernet interface design.  The
 existing ones are quite lacking in many ways, and put far too much
 load on the processor.  If you're going to design one, I have some ideas
 for what would be useful.  There were some interesting designs presented
 at Sigcomm '88 which address some of the problems I have with current
 designs, though not all of them.]

    Finally, since I cc'd this to tcp-ip, all of the above is
    Copyright (c) 1988 by John Carter.  This way, I don't get
    misquoted and, more importantly, Van doesn't get misquoted
    by my references to his work.
    

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 16:45:40 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

In article <8810251528.AA04950@braden.isi.edu> braden@VENERA.ISI.EDU writes:
>Your box is going to have several different shades of yellow lights on it,
>shading between red and green...

No, better it should have a bar-graph display; all those yellow lights
will be hard to tell apart.  Now, what units would TCP/IP non-compliance
be expressed in?  Obviously the technical name of the quantity being
measured is something like "bogosity", but what are the units?  :-)

(By analogy to whetstones and dhrystones and the like, I'm tempted to
suggest "Millstones"!)
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 16:54:58 GMT
From:      sam@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   TCP-IP Information

Two good books on TCP/IP that helped acclimatize me to the networking world:

	- "An Introduction to TCP/IP" by John Davidson
	  Publisher: Springer-Verlag

	  This is a small thin book with lots of diagrams.  You can zip
	  through it on a Sunday afternoon.  It concentrates mostly on IP
	  on Ethernet, but does a good breakdown of packet contents and 	
	  details each of the 7 OSI Model layers in separate chapters.

	- "Internetworking with TCP/IP" by Douglass Comer	
	  Publisher: Prentice Hall

	  Not exactly Sunday afternoon reading, this is a big, thick textbook-
	  format book.  Has worked well for me as a reference when I've needed
	  detailed information about something in particular.  Perhaps if you
	  ask, the nice person who posted a very detailed review of this book
      about a month ago will send you a copy.


Shelli Meyers
FTP Software, Inc.

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 16:56:49 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

Barry Margolin (Thinking Machines Corp) writes:

>The problem isn't that TELNET can't do what RLOGIN does, it's that
>nobody bothered to define the necessary TELNET enhancements before
>RLOGIN proliferated.  I think it's too late, and anyone who thinks
>that RLOGIN can be phased out is dreaming.

As if TELNET and RLOGIN weren't enough, there are folks busily 
developing a new standard for the ISO Virtual Terminal Protocol.

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 16:59:24 GMT
From:      bae@unisoft.UUCP (Hwa Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet v.s. rlogin

One of the disturbing features of 4.3 telnet daemon implementation is that
it assumes that the remote telnet client knows about TTYPE negotiation
at the beginning of the session establishment.  I ahd a case where our
version of telnet client would talk to all other systems but 4.3 based
telnetd.  4.3 telnetd will hang there waiting for the DO TTYPE command.
This also makes it harder for UUCP clients that try to use telnet connection
to do UUCP over network; unless UUCP client connecting to the 4.3 telnetd
WKP sends WONT DO TTYPE message initially, it will hang forever waiting.

/hjb
-- 
----------- "I am no Jack Kennedy."  ------------------------------
 Hwa Jin Bae               bae@tis.llnl.gov       (Internet)
 UniSoft                   bae@unisoft.UniSoft    (smail uucp)
 Emeryville, CA            ...!uunet!unisoft!bae  (plain uucp)

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 17:02:37 GMT
From:      jam@radc-lonex.arpa
To:        comp.protocols.tcp-ip
Subject:   Re: telnet v.s. rlogin

>>  The design of telnet implies that data is
>>  always sent in segments with a line terminator.
>
>I presume you're talking about go ahead.  That is almost never used.
>When you're talking to a full-duplex host you negotiate it off.
>Except for Braden's MVS implementation, even software for IBM hosts
>doesn't do go aheads.  This option appears to be defunct.
>

	No (Gee, that sounds rather harsh, doesn't it?) I'm not.  And
	this is right, GA (goahead) does seem to be defunct.

	Telnet still has idea that stuff should be sent on a line by
	line basis.  This is almost never the case, but telnet still
	pretty much requires a line terminator sequence of <CR><LF>
	which is usually inserted wherever the user pressed the return
	key.  This is normally translated to whatever the host system
	requires as a line terminator (on UNIX this becomes <LF>).

	The ability exists to send a <CR> exists by sending <CR><NUL>.
	RFC1053 proposes the addition of a negoiation between the
	host and remote to send <CR><LF> or <CR><NUL> when the user
	presses the return key.  This would allow the host computer
	to decide what it wanted, line terminators or just whatever
	the user typed, without going into BINARY mode (which has
	some other side effects).

	Merton Crockett, John Ada, and I orignally opened that can of
	worms a year ago.   It was nice to see it added to that RFC.
	But it was just proposed, and I do not know if it was ever
	'offically' adopted.  But as far as I know, BSD4.3 UNIX does
	not support that negoiation.  I'm not sure if other systems do.
	Does anyone know?

Joel

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 17:43:00 GMT
From:      yurcik@LCP.NRL.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Capital-area Meeting to discuss Network Security

TCP-IP Implementers in the area might be interested in attending
this meeting.  



*******************************************************************************
   The George Mason University School of Information Technology and Engineering
            and the Virginia Cooperative Graduate Engineering Program
   
                                     present
   
         Professional Development from the University of Maryland and the
       Washington D. C. Chapter of the Association for Computing Machinery
   
                 RECENT DEVELOPMENTS IN COMPUTER NETWORK SECURITY
   
                      An Interactive Televised Short Course
              Wednesday, November 9, 1988; 11:00 A. M. to 5:00 P. M.
   
Intended audience: The course is designed for senior technical managers in 
                   data processing, information systems and network 
                   environments in user organizations; senior development 
                   staff in hardware and software; manufacturer and supplier 
                   organizations; and consultants involved in OSI planning and 
                   implementations. 
   
Description:       This six-hour course presents an overview of recent 
                   developments in network security, emphasizing the Open 
                   System Interconnection (OSI) security architecture 
                   developed by the International Standards Organization and 
                   the Trusted Network Interpretation (TNI) developed 
                   by the National Computer Security Center.
   
                            *  Introduction to access control and authentication
                            *  Using encryption for authentication
                            *  Mandatory and discretionary access control
   
Location:      George Mason University; Science and Technology Building
               Rooms 110 and 112
               Parking is available in Lot B or in the Patriot Center Lot.
               Please stop at an Information Booth for a parking permit.
   
Registration:  Reservations are requested prior to Friday, November 4.  
   
To register please contact:  Mrs. Kathleen Jones
                             Cooperative Graduate Engineering Program
                             George Mason University
                             101 Science and Technology Building
                             Fairfax, VA 22030
                             323-3194

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Oct 88 17:25:23 CET
From:      Michael Nittmann <ZREN%DS0RUS1I.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Reliable Datagrams
Ok. they are unreliable and nonreliable.(checksum only for header!).

Michael.

 ------------------------------------------------------------------
    Address:                            Local Office:
 Cray Research GmbH                    Cray Research Software Office
  Michael Nittmann                       Michael Nittmann
 Networking Support                  c/o
                                              RUS
 Kistlerhofstr. 168                  UNIVERSITY OF STUTTGART
    8 Munich 71                          Allmandring 30
     Germany                              7 Stuttgart 1
                                            Germany
 E-mail and reply to:                      Phone:
 UG051%CRAYAMID.CRAY.COM@UMN-REI-UC.ARPA   0711/6855847 or 0711/6874767
Acknowledge-To: <ZREN@DS0RUS1I>
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 19:04:52 GMT
From:      fluke!ssc-vax!bruce@beaver.cs.washington.edu  (Bruce Stock)
To:        tcp-ip@sri-nic.arpa
Subject:   Previous Posting "RE:Wierd ARP"
line eater



In a recent posting I inadvertently slighted two (3?) vendors.  First,
by referring to Network General (makers of The Sniffer) as "Data General", and 
secondly by using the term "Lanalyzer" to refer to a generic network analyzer.

While Network General was content to suffer in silence, not so Excelan:

(Excerpted for brevity)

>LANalyzer is a registered trademark of Excelan, Inc.  It
>refers to our EX 5100, EX 5300, and EX 5500 products which
>compete head-to-head with Network General's "Sniffer" product
>line.  

>We're proud of our product, jealous of our trademark, and
>anxious to not have our trademark become a generic term.  
>Accordingly, I ask you to please make another posting
>to comp.protocols.tcp-ip.  Please explain the general
>situation to the newsgroup readership, with special attention 
>to noting that:
> 1) LANalyzer is a registered trademark that denotes a 
>    particular product, and
> 2) Excelan Inc. values this trademark highly.  
>
>Thank you very much!
>--
>Chuck Kollars,  Excelan, Inc.	mtxinu!excelan!chuck@ucbvax.Berkeley.EDU


	OK Chuck.  Done.
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 19:33:26 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: is there a need for class A addresses?

In article <5857@vdsvax.steinmetz.ge.com> barnett@vdsvax (Bruce G. Barnett) writes:
>Well, If you expect to have the number of machines a company like GE 
>expects, there is some advantage to getting a single block of numbers
>and assigning the network numbers from one organization.

You don't need a class A network for this.  You could get a whole
bunch of class B or C networks, and then hand them out as departments
set up new networks.  At Thinking Machine we received about ten class
C networks, and we use about half of them so far for our various
internal networks.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 20:02:09 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

>According to Mike Karels, there are no plans to write specifications
>for the protocols used by the r-commands because they were originally
>hacks to try out TCP and should die a natural death.  If they were
>documented, then people would be implementing them, they would
>proliferate, and there would be no getting rid of them.

Just like Sun and ND (yes, that's why it was never published)....

>The party line is that 4.3 telnet is better anyway, so we should all be
>using that.

If "4.3" means "4.3BSD", rather than "4.3-tahoe", this isn't quite true;
the 4.3BSD "telnet" doesn't pass the screen size over the wire, while
the 4.3BSD "rlogin" does so every time it changes.  I don't think I
found any TELNET option to do that when I looked for one, but this
doesn't mean it isn't there - is there such an option?  Has one been
proposed?

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 20:05:17 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

>Don't forget the transparency.  Full 8 bit file transfers (like uucp 'g')
>don't work over telnet).

Do people run UUCP over "rlogin"?  If so, and the UUCP on both ends
supports it, they should consider running UUCP with the 't' protocol
directly over TCP instead.

TELNET does have a binary mode; I don't know if this is the Right Thing
here or not.  It would be nice to have it support character sets wider
than 7 bits - in fact, it would be nice to have it support character
sets wider than 8 bits....

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 20:51:29 GMT
From:      dab@opus.CRAY.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)


To fix a telnet client so that you can flush output when you type ^C
is really not very hard, and can be done without modifying the telnet
server.  When the client sends the IAC IP (sent when the user types ^C,
or whatever the interrupt character is (What? your telnet doesn't send
IAC IP? Well, since you're changing it anyway, add a user option to say
what character should be translated to IAC IP)), also send a IAC DO
TIMING-MARK.  You then proceed to throw away all data until you see a
IAC WILL/WONT TIMING-MARK, at which point you resume output.  All telnet
servers should respond to the DO TIMING-MARK, regardless if they support
it or not (if they don't, then you have a real brain-dead telnetd
implementation, even 4.2 responds).

The only problem with this fix is that depending on how long the pipe
is, you may sit there for several seconds while the output is being
discarded, but at least it won't scroll off the screen.  A good telnet
implementation should allow you to do both TIMING-MARK and SYNC, so
that you can choose whatever works best.

			-Dave Borman, Cray Research, Inc.

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 20:55:09 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re:  Specification of Berkeley networking utilities


    (1) A TELNET server that supports such a feature could send IAC DO
    SEND-USERNAME (a new option I just made up) before sending the
    "login:" prompt.  If the client supports this it will respond with IAC
    WILL SEND-USERNAME and then uses the subnegotiation mechanism to send
    the name.  The server would then bypass the normal login prompt and
    log the user in, subject to access checks like those rlogin does.

Actually, I think this capability is already defined in TELNET. Take a look at
RFC927 for the details.

	Vince Fuller, Stanford Networking
-------

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Oct 88 01:03:59 EDT
From:      Steve Howie <SCOTTY%UOGUELPH.BITNET@CORNELLC.ccs.cornell.edu>
To:        TCP-IP Redistribution list <TCP-IP@SRI-NIC.ARPA>
Subject:   re: TCP-IP Information
I Believe IBM are making plans to sell this book through their regular
documentation channels. Kinda neat concept, eh? :)
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 21:21:42 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP terminalservers and BREAK(/^C)

The primary problem is that a terminal server has no way of knowing
which characters are magic.  For example, pretend you come from a DEC
background, and think that ^O should start to flush output.  If you type
^O to the terminal server, and it blindly starts discarding output and
send telnet abort-output to the host, this might be fine.  On the other
hand, you might be in EMACS, and now expect ^O to create a new line. oops.
(I actually used a telnet that handled ^O locally.  It was a pain.)

There is an RFC being written that provides for "local signal handling",
and negotiation of signal characters.  When this rfc goes into effect,
and is implemented by vendors (both host and terminal servers), things
should get a lot better...

Bill Westfield
cisco Systems.
-------

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 88 21:56:47 GMT
From:      kmont@hpindda.HP.COM (Kevin Montgomery)
To:        comp.protocols.tcp-ip
Subject:   RPC talking OSI?


	Has anyone seen a copy of RPC that speaks an OSI protocol
instead of using UDP?  Anyone at TWG (or anyone else) have anything 
like this available either now or in the works?

					adv -thanks- ance,
					  kevin

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 01:16:12 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for IBMs?

The 4381 and the 9370 can both talk to the Token Ring with an 8232 which
is not so hot, but it is what IBM has right now.  The 8232 is a second
generation of a DACU only this time rather than having something useful
like a UNIBUS, it's an industrial channel attached IBM-PC.  If you could
deal with plugging the machines into Ethernet, BusTech makes a much cheaper
and better performing channel attached Ethernet controller.  The 9370 can
also be attached to the network without the 8232 because there are integral
lan interface cards available.

The Series 3X (and the AS/400) are going to be more interesting.  I don't
think IBM has gotten that far in pushing TCP/IP.  Mostly at the last SHARE
IBM was tripping over themselves insisting that their support of TCP/IP and
UNIX was not an indication that these would supplant SNA and SAA respectively.

-Ron

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Oct 88 09:01:29 edt
From:      snorthc@NSWC-OAS.ARPA
To:        tcp-ip@sri-nic.ARPA
Subject:   re NetBIOS/TCP (UDP)
To: tcp-ip@sri-nic.arpa

> From: hpda!hpcupt1!hpisod1!renglish@ucbvax.Berkeley.EDU  (Robert English)

> Saying "users don't want to be bothered" trivializes the issue somewhat.
> There are many DOS applications in which users never see the actual
> files involved.  The application presents them with menus to perform
> tasks, and manages the files itself.  A user who had to transfer all of
> the necessary files over via FTP would have to be much more
> sophisticated than one who merely used the application.

I agree with most of what you say above.

> Furthermore, there is the issue of file-sharing.  If users access the
> files on the remote machine directly, they can share effectively share
> data with other users.  If they must copy the data back and forth, they
> are likely to get inconsistent versions, forget to do the copies, etc.
> (I know, you've never walked away from a terminal without writing out a
> file).

> Working in a non-transparent environment is significantly more
> complicated than working in a transparent one.

Here is where I have the problem.  If you are talking theory or ideals
you are right of course.  If you are talking implementations of
NetBIOS/TCP then perhaps the memory issue needs to be revisited.
If you have an MS-DOS machine, you may find 256k or so of your available
memory space gone to provide this transparency (example 3c505, FTP SW,
IBM PC LAN program rdr).  Cut off another 60 - 80k for DOS and many
of the applications that provide the user with menus and manage the
files cannot run.  Then what does transparency buy you?

There are work arounds.  The Excelan implementation requires
less memory, I think it was about 80k for RDR.  Also for those
with 80386 chips there are supposedly programs that allow TSR type
SW or device drivers to run in memory space above 1mb.  There is
also OS/2 [I'm still waiting for the promised Oct update to my SDK
Microsoft!!!!].  However, for the present, I have serious
doubts that NetBIOS/TCP is providing usable services to anyone.
It is my belief that the vendors who invested time/effort/
brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan,
Bridge [they weren't 3Com at the time], Network Research Corp) wish
they had placed their investment somewhere else like NFS or OSI or
whatever.

Finally file sharing.  A simple file locking scheme may not be
sufficient to make file sharing truly useful.  Ever write code
with someone else?  What if the only mechanism for
Source Code Control was that the file was locked after
a user had it?  That is why we RCS and friends.  I have never
written a document with anyone else, but I suspect you would
run into some of the same problems.  This is why multi-user
databases handle their own locking (one reason they require so
much memory).  The point is you are still likely to get inconsistent
versions with NetBIOS/TCP as your file sharing mechanism.  It is
not clear to me that an incomplete, memory hogging, broadcast based,
transparent environment is less complicated than simply explictly
transferring files with a mechanism like FTP or FTAM.  Don't listen
to me though, I wasn't able to figure out what a PS/2 would buy me
either and do my development work on a Compaq, you see, I have already
missed the boat :).

Stephen Northcutt (snorthc@relay-nswc.navy.mil)

Disclaimer: I have no financial ties with any commercial vendor mentioned.
I am NOT against transparency.  I haven't even given up on NetBIOS
(should the OS/2 extensions prove to work out).  It is simply my
personal opinion that NetBIOS/TCP for DOS is not a workable solution.
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 05:03:59 GMT
From:      SCOTTY@UOGUELPH.BITNET (Steve Howie)
To:        comp.protocols.tcp-ip
Subject:   re: TCP-IP Information

I Believe IBM are making plans to sell this book through their regular
documentation channels. Kinda neat concept, eh? :)

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Oct 88 15:34:58 EDT
From:      bzs@bu-cs.BU.EDU (Barry Shein)
To:        map@gaak.LCS.MIT.EDU
Cc:        dab%opus.CRAY.COM@uc.msc.umn.edu, jam@radc-lonex.arpa, mcvax!cernvax!cgch!cgcha!whna@uunet.uu.net, tcp-ip@sri-nic.arpa
Subject:   TCP/IP terminalservers and BREAK(/^C)

>Except that the client end can't possibly have enough information
>about what is and isn't going to cause output to be flushed, only the
>server end (and maybe the user if they know the insides of the server)
>can know that.  You can't expect a user to type magic commands
>frequently so for this scheme to work you need to add new options in
>TELNET to allow the server to tell you every time this changes.  These
>will have the same implementation problem that GA had (see parallel
>discussion) where the server process can't get at the information.
>All in all, I think this suggestion only makes the problem harder to
>solve right.  Given the underlying TCP functionality, I think the
>original Abort Output (AO) is the best we're going to do, except for
>the problem of implementing it in some cases.
>
>	Mike Patton, Network Manager
>	Laboratory for Computer Science
>	Massachusetts Institute of Technology

"Can't possibly"? I find that hard to believe. It might require a
generic set of options which a host has to pass depending on state
changes in a form telnet can understand, but certainly there aren't
that many, are there? There are many existant front ends, some from
the last decade, which seemed to have been able to do this sort of
thing.

Now, is it worthwhile? Different question, to be honest the lack never
bothered me much (tho I've gone around it with people in my office who
did seem to be bothered.)

	-Barry Shein, ||Encore||

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 13:01:29 GMT
From:      snorthc@NSWC-OAS.ARPA
To:        comp.protocols.tcp-ip
Subject:   re NetBIOS/TCP (UDP)

To: tcp-ip@sri-nic.arpa

> From: hpda!hpcupt1!hpisod1!renglish@ucbvax.Berkeley.EDU  (Robert English)
 
> Saying "users don't want to be bothered" trivializes the issue somewhat.
> There are many DOS applications in which users never see the actual
> files involved.  The application presents them with menus to perform
> tasks, and manages the files itself.  A user who had to transfer all of
> the necessary files over via FTP would have to be much more
> sophisticated than one who merely used the application.

I agree with most of what you say above.

> Furthermore, there is the issue of file-sharing.  If users access the
> files on the remote machine directly, they can share effectively share
> data with other users.  If they must copy the data back and forth, they
> are likely to get inconsistent versions, forget to do the copies, etc.
> (I know, you've never walked away from a terminal without writing out a
> file).
 
> Working in a non-transparent environment is significantly more
> complicated than working in a transparent one.

Here is where I have the problem.  If you are talking theory or ideals
you are right of course.  If you are talking implementations of
NetBIOS/TCP then perhaps the memory issue needs to be revisited.
If you have an MS-DOS machine, you may find 256k or so of your available
memory space gone to provide this transparency (example 3c505, FTP SW,
IBM PC LAN program rdr).  Cut off another 60 - 80k for DOS and many
of the applications that provide the user with menus and manage the
files cannot run.  Then what does transparency buy you?

There are work arounds.  The Excelan implementation requires
less memory, I think it was about 80k for RDR.  Also for those
with 80386 chips there are supposedly programs that allow TSR type
SW or device drivers to run in memory space above 1mb.  There is
also OS/2 [I'm still waiting for the promised Oct update to my SDK
Microsoft!!!!].  However, for the present, I have serious
doubts that NetBIOS/TCP is providing usable services to anyone.
It is my belief that the vendors who invested time/effort/
brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan,
Bridge [they weren't 3Com at the time], Network Research Corp) wish
they had placed their investment somewhere else like NFS or OSI or
whatever.

Finally file sharing.  A simple file locking scheme may not be
sufficient to make file sharing truly useful.  Ever write code
with someone else?  What if the only mechanism for
Source Code Control was that the file was locked after
a user had it?  That is why we RCS and friends.  I have never
written a document with anyone else, but I suspect you would
run into some of the same problems.  This is why multi-user
databases handle their own locking (one reason they require so
much memory).  The point is you are still likely to get inconsistent
versions with NetBIOS/TCP as your file sharing mechanism.  It is
not clear to me that an incomplete, memory hogging, broadcast based,
transparent environment is less complicated than simply explictly
transferring files with a mechanism like FTP or FTAM.  Don't listen
to me though, I wasn't able to figure out what a PS/2 would buy me
either and do my development work on a Compaq, you see, I have already
missed the boat :).

Stephen Northcutt (snorthc@relay-nswc.navy.mil)

Disclaimer: I have no financial ties with any commercial vendor mentioned.
I am NOT against transparency.  I haven't even given up on NetBIOS
(should the OS/2 extensions prove to work out).  It is simply my
personal opinion that NetBIOS/TCP for DOS is not a workable solution.

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 13:31:40 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)

I think the original discussion was more concerned with the continued receipt
of data after a ^C (IAC IP).  Few operating systems will do anything about
flushing data from the transmit queue on receipt of a ^C (IAC IP) although
many will flush data from the receive queue on receipt of the ^C.  If the
intent is to stop the display of data on the local terminal, then ^O (IAC AO)
should be used.  The TELNET server should then toss the received data into
the bit bucket until a SYNC is received from the remote system.

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 13:50:02 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP terminalservers and BREAK(/^C)

Just a curiosity?  Why does EMACS use a ^O to create a new line?  It would
seem that the existing ENTER and RETURN keys should work fine; however, it
does point out a need for the host and terminal servers to have some mechanism
for establishing what are significant keys and their implications.

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 15:18:06 GMT
From:      guru@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   Re: "Reliable Datagram" is an Oxymoron


> The word combination "Reliable Datagram" is an Oxymoron.  By definition a
>   datagram can not be reliable.  See RFC-791 Section 1.

On similar lines, it is important to understand that every 
connection-oriented protocol is not necessarily reliable, and it does
not necessarily use complex hop-to-hop and/or end-to-end flow and error
control mechanisms. 

I believe very soon we will have a situation where we cann't
differentiate between a quasi-reliable connection protocol and a
"smarter" datagram protocol except probably for their names.  

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899 
(314) 889-4621

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 15:24:47 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

Wow!  This time everyones getting into the act!  This is great, a perfect
example of how this forum should be used!

I want thank and applaud everyone who threw their hat (and nickle) into
the ring.  And now for a few comments on items that I have received...

To Stuart Levy (slevy@us.msc.umn.edu):

	Sorry if I sounded too discouraged.  I didn't quite mean to be
	that bad, I mostly meant that it will probably be a while before
	the manufacturers' of terminal servers get things on an even
	keel about this.  I suspect most of them would welcome some of
	the improvements being considered.

	I agree with you on both the "open" and "closed" loop flushing
	mechanisims.  The open-loop is implemented in many cases, but
	due to the speed of the network a lot can get through before
	things catch up.  The closed loop is obviously the one of choice,
	and I'm glad to hear that Dave Borman's group is working on it.
	If I hadn't said something about the problems, I wouldn't have
	heard about the work!  Last year we were a cry in the wilderness,
	seems like a lot of people have been thinking about telnet
	improvments since that echo last rebounded.  A couple of new
	RFCs supports that theory!


To Dave Borman (who just received honorable mention!):
	(dab%opus.cray.com@uc.msc.umn.edu):

	Thanks for the info!  Actually I was aware of IAC IP, but it still
	doesn't solve the problem of exactly what is the interrupt character?
	I was trying to make the point that there needs to be a mechanisim
	to update telnet clients when modifications are made on the fly.
	UNIX allows ^C to be changed, other systems might not.  Stuart
	tells me your group is tackling this, I wasn't aware of that!
	Sitting at RADC I sort of get things weeks, months, yes even years
	late.


Rob Austein (sra@xx.lcs.mit.edu):

	I have to go back to studying my writing skills.  I didn't mean
	that the server queues up a line and then sends it.   What I
	did mean to say is that the old specification of telnet was designed
	around the idea of line orientated systems, hence the end-of-line
	sequence (<CR><LF>) which can be interpreted differently by different
	host servers.

	I should point out that were I said UNIX treats <CR><LF> as <LF>
	this applies to older UNIX systems.  4.3 was patched after last
	years discussion to make it <CR>, which solved a lot of problems.
	I'll get to more of this in a minute.


Charles Hedrick (hedrick@aramis.rutgers.edu):

	Charles Hedrick feels that the <CR><LF> question is probably going to
	go away.  This is probably the case, more so with so many people
	diving into it.

----

Let me see if I can get a better handle on what the problem actually
was.  There are still many telnet servers which want to take <CR><LF>
and make it the default end-of-line on their computer.  Pre 4.3
update UNIX systems, and MULTICS systems, make this a <LF> because
that is what a normal line termination is.  Not a bad choice actually.
BUT, what about getting a <CR> when you are playing with some fancy
software on the remote host?

All telnet servers should have treated <CR><NUL> as a <CR>, and
passed that on through.  No problem there, except for a lot of
telnet clients that always treated (and still do) the <CR> key
as end-of-line and sent <CR><LF>.  That means that many hosts
never will see a <CR> arrive on the other side of a telnet server.
4.3 just gave up on the idea and decided that end-of-line meant
use a <CR>.  Which is the easiest solution.  If only everybody
did it!

The negoiations proposed last year, and being reproposed (by others)
now, merely offer a way for the host to tell the client that, hey,
I want to see REAL carriage returns when the user types them.

And more power to those designing better ways to handle things like ^C, ^O.

----

The above is for the benifit of those persons who have not had much
idea of exactly what was being bandied about.  Personally I was
glad I pried the subject open, because I was not aware of the work
being done by others.  If the appropriate RFCs are written and
accepted, this should all eventually come out in the wash.

Joel
(The opinions here are of course only my own)

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 15:25:54 GMT
From:      mckee@CORWIN.CCS.NORTHEASTERN.EDU (George McKee)
To:        comp.protocols.tcp-ip
Subject:   up-to-date RFC/protocol index?

Hi.
I have a copy of RFC 961, "Current Official Arpanet Protocols" which
has a notation that it "Obsoletes: RFCs 944, 924, 901, 880, 840" but
(since it's on paper) it has no "Is Obsoleted by: RFCs (mumble)".
Is there any place I can look to find out what today's version of
the official list is, where "today" varies from time to time, but
the place I look doesn't?

	- George McKee
	  NU Computer Science

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 15:51:37 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP terminalservers and BREAK(/^C)


   Date: Thu, 27 Oct 88 15:51:29 CDT
   From: dab%opus.CRAY.COM@uc.msc.umn.edu (Dave Borman)

   To fix a telnet client so that you can flush output when you type ^C
   is really not very hard, and can be done without modifying the telnet
   server.  When the client sends the IAC IP (sent when the user types ^C,
   or whatever the interrupt character is (What? your telnet doesn't send
   IAC IP? Well, since you're changing it anyway, add a user option to say
   what character should be translated to IAC IP)), also send a IAC DO
   TIMING-MARK.  You then proceed to throw away all data until you see a
   IAC WILL/WONT TIMING-MARK, at which point you resume output.  All telnet
   servers should respond to the DO TIMING-MARK, regardless if they support
   it or not (if they don't, then you have a real brain-dead telnetd
   implementation, even 4.2 responds).

Except that the client end can't possibly have enough information
about what is and isn't going to cause output to be flushed, only the
server end (and maybe the user if they know the insides of the server)
can know that.  You can't expect a user to type magic commands
frequently so for this scheme to work you need to add new options in
TELNET to allow the server to tell you every time this changes.  These
will have the same implementation problem that GA had (see parallel
discussion) where the server process can't get at the information.
All in all, I think this suggestion only makes the problem harder to
solve right.  Given the underlying TCP functionality, I think the
original Abort Output (AO) is the best we're going to do, except for
the problem of implementing it in some cases.

	Mike Patton, Network Manager
	Laboratory for Computer Science
	Massachusetts Institute of Technology

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

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 16:01:00 GMT
From:      snorthc%NSWC-OAS.ARPA.CP6%LADC@BCO-MULTICS.HBI.HONEYWELL.COM (snorthc)
To:        comp.protocols.tcp-ip
Subject:   re NetBIOS/TCP


> From: hpda!hpcupt1!hpisod1!renglish@ucbvax.Berkeley.EDU  (Robert English)
 
> Saying "users don't want to be bothered" trivializes the issue somewhat.
> There are many DOS applications in which users never see the actual
> files involved.  The application presents them with menus to perform
> tasks, and manages the files itself.  A user who had to transfer all of
> the necessary files over via FTP would have to be much more
> sophisticated than one who merely used the application.

I agree with most of what you say above.

> Furthermore, there is the issue of file-sharing.  If users access the
> files on the remote machine directly, they can share effectively share
> data with other users.  If they must copy the data back and forth, they
> are likely to get inconsistent versions, forget to do the copies, etc.
> (I know, you've never walked away from a terminal without writing out a
> file).
 
> Working in a non-transparent environment is significantly more
> complicated than working in a transparent one.

Here is where I have the problem.  If you are talking theory or ideals
you are right of course.  If you are talking implementations of
NetBIOS/TCP then perhaps the memory issue needs to be revisited.
If you have an MS-DOS machine, you may find 256k or so of your available
memory space gone to provide this transparency (example 3c505, FTP SW,
IBM PC LAN program rdr).  Cut off another 60 - 80k for DOS and many
of the applications that provide the user with menus and manage the
files cannot run.  Then what does transparency buy you?

There are work arounds.  The Excelan implementation requires
less memory, I think it was about 80k for RDR.  Also for those
with 80386 chips there are supposedly programs that allow TSR type
SW or device drivers to run in memory space above 1mb.  There is
also OS/2 [I'm still waiting for the promised Oct update to my SDK
Microsoft!!!!].  However, for the present, I have serious
doubts that NetBIOS/TCP is providing usable services to anyone.
It is my belief that the vendors who invested time/effort/
brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan,
Bridge [they weren't 3Com at the time], Network Research Corp) wish
they had placed their investment somewhere else like NFS or OSI or
whatever.

Finally file sharing.  A simple file locking scheme may not be
sufficient to make file sharing truly useful.  Ever write code
with someone else?  What if the only mechanism for
Source Code Control was that the file was locked after
a user had it?  That is why we RCS and friends.  I have never
written a document with anyone else, but I suspect you would
run into some of the same problems.  This is why multi-user
databases handle their own locking (one reason they require so
much memory).  The point is you are still likely to get inconsistent
versions with NetBIOS/TCP as your file sharing mechanism.  It is
not clear to me that an incomplete, memory hogging, broadcast based,
transparent environment is less complicated than simply explictly
transferring files with a mechanism like FTP or FTAM.  Don't listen
to me though, I wasn't able to figure out what a PS/2 would buy me
either and do my development work on a Compaq, you see, I have already
missed the boat :).

Stephen Northcutt (snorthc@relay-nswc.navy.mil)

Disclaimer: I have no financial ties with any commercial vendor mentioned.
I am NOT against transparency.  I haven't even given up on NetBIOS
(should the OS/2 extensions prove to work out).  It is simply my
personal opinion that NetBIOS/TCP for DOS is not a workable solution.

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 16:56:42 GMT
From:      SOL@SRI-NIC.ARPA (Sol Lederman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP terminalservers and BREAK(/^C)

In emacs, ^O puts the end-of-line character(s) into your editing buffer and 
leaves the cursor at the same place it was in before the ^O was pressed. 
Hitting Return puts the same end-of-line character into your buffer but
the cursor is repositioned to be after the end-of-line character. The
difference might appear to be subtle but it's handy to have the option of
where you want your cursor to be after hitting Return.

Sol

Disclaimer: This is the way ^O seems to work on TOPS-20 emacs. I haven't
checked other versions.
-------

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Oct 88 18:44:06 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification of Berkeley networking utilities

In article <211@cwjcc.CWRU.Edu> chet@pirate.UUCP (Chet Ramey) writes:
>Mike Karels... said he hoped that if that stuff got
>into Telnet, rlogin and friends could just fade away quietly without
>proliferating. 

I'm afraid he's being wildly optimistic.  The time to kill rlogin and
friends was five minutes before the 4.2 tapes started shipping.  It's
far too late now.

>(Christ, Henry, don't you ever have anything nice to say about Berkeley?
>Even once? (Henry? Say something nice about Berkeley? It is to laugh! :-))

You wound me, sir.  I said something nice about Berkeley just last year. :-)

Actually, they've done a lot of good stuff, and the world is better off
with them than without them, but the world (especially the networking
world) would be a nicer place if some of the effort that went into
(e.g.) 1986's wonderful new ideas had gone into rethinking and cleaning
up (e.g.) 1985's.
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 20:53:27 GMT
From:      SOL@SRI-NIC.ARPA (Sol Lederman)
To:        comp.protocols.tcp-ip
Subject:   Re: up-to-date RFC/protocol index?

George,

The NIC maintains an RFC index which is updated whenever a new
RFC is announced. You can retrieve the index via FTP (host: sri-nic.arpa,
user: anonymous, password: guest, file: rfc:rfc-index.txt) or by
electronic mail (send a message to service@sri-nic.arpa with the words
RFC INDEX in the subject line).

The index shows that RFC 961 has been obsoleted by RFC 991 which has been
obsoleted by RFC 1011, "Official Internet Protocols", issued in May, 1987.

Sol/NIC
-------

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 21:08:20 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Getting TELNET Abort Output right

Yes, I did really mean "can't possibly"!  I use so many different
systems which do so much different terminal processing including
sometimes changing the effect of characters between when I type-ahead
and when they are actually acted upon, that I am convinced that a
client alone doesn't stand a chance of coming close to getting this
right.  Even the server will have a hard time due to the architecture
of most operating systems making it difficult for the TELNET server to
get this information from the actual user program (ref the other
discussion on GA) where the knowledge may actually reside.

	Mike Patton, Network Manager
	Laboratory for Computer Science
	Massachusetts Institute of Technology

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

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 22:09:20 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re:  Specification of Berkeley networking utilities

In article <12441844876.13.VAF@Score.Stanford.EDU> VAF@SCORE.STANFORD.EDU (Vince Fuller) writes:
>
>    (1) A TELNET server that supports such a feature could send IAC DO
>    SEND-USERNAME (a new option I just made up) before sending the
>Actually, I think this capability is already defined in TELNET. Take a look at
>RFC927 for the details.

So it is.  I guess great minds think alike.

One problem with the protocol in RFC927, though, is that the userid
that is transmitted is interpreted as a 32-bit binary number.  Not all
OSes have numeric userids, though.  Multics and Genera both use
character string user names, and don't translate them into numbers
internally.

Why was the protocol defined in such a restrictive manner?

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 88 22:27:27 GMT
From:      zz1he@sdcc19.ucsd.EDU (Heather Ebey)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.sys.ibm.pc
Subject:   NCSA Telnet 2.2 for pc problem



NCSA Telnet will not make a connection.  The regular PC-NFS Sun
telnet will.

NCSA Telnet reports:
"Conflict with Ethernet hardware address <gives address>
 ERROR: The conflicting machine is using the same IP number."

There is only one ethernet card in the machine: a 3COM.
First, there is no other card in-house using this ethernet address
or IP number.  I checked the distributed /etc/hosts for a duplicate
IP.  Besides, PC-NFS doesn't complain.

We opened the machine and moved boards around, checked the interrupt/DMA/
I/O address on the 3COM board (it is using the factory defaults).
We removed every board except another 3COM (from another micro and even
put in the video card that was in the other micro), the sub-system board
and and the disk drive controller..

Each time we made a change, we turned the micro back on and tested it.

We tried the ethernet card in another micro, works fine.

What's more confusing is that the NCSA Telnet will work once
and then gives the above message if the micro is rebooted.  This is
rebooting without making any changes.

We removed all our drivers from config.sys except the 3c501.sys.

Has anyone seen this problem?  Does anyone have the source code
and can tell what failure is generating this message?
	--Heather Ebey

-----------------INTERNET: hebey@ucsd.edu--------------------
Heather Ebey, MicroLab Support       Voice:  (619) 534-2448
UCSD, Academic Computing Center, C-010, La Jolla, CA. 92093
-----------------BITNET:  hebey@ucsd.bitnet------------------

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 88 00:06:48 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: up-to-date RFC/protocol index?


George McKee:

Hi.  The latest "Official Protocols" is RFC-1011.  The current list of RFCs

is available in the file RFC:RFC-INDEX.TXT on the host SRI-NIC.ARPA.

--jon.

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 88 03:09:23 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

henry@utzoo.uucp (Henry Spencer) writes:
> Obviously the technical name of the quantity being measured is something
> like "bogosity", but what are the units?  :-)

	Given that the quantity is bogosity, and the universe in which this
quantity exists is the swamp, it seems that "the bog" is the obvious name for
the unit of measure.  Next question; do we define a fixed goodness-to-badness
continium with 1 bog being totaly bogus (thus, a 10 decibog box would be 90%
in compliance with the specs) or do we define an open-ended scale, on the
assumption that no matter how bad something is, somebody will always manage
to come along with something worse?
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 88 06:26:32 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re:  Specification of Berkeley networking utilities

>    (1) A TELNET server that supports such a feature could send IAC DO
>    SEND-USERNAME (a new option I just made up) before sending the
>    "login:" prompt. ....
>
>Actually, I think this capability is already defined in TELNET. Take a look at
>RFC927 for the details.

Not quite.  RFC927 specifies that the hosts exchange a 32-bit "UUID",
not a name; "rlogin"s auto-login feature permits the same user name to
have different UNIX numeric user IDs.

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 88 06:40:59 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet v.s. rlogin

>One of the disturbing features of 4.3 telnet daemon implementation is that
>it assumes that the remote telnet client knows about TTYPE negotiation
>at the beginning of the session establishment.

Another problem with TTYPE, although less serious, is that, while RFC930
says

   The terminal type information is an NVT ASCII string.  Within this
   string, upper and lower case are considered equivalent.  The complete
   list of valid terminal type names can be found in the latest
   "Assigned Numbers" RFC.

and RFC1010, "Assigned Numbers", lists (for example), under Terminal
Type Names, "DEC-VT100".  However, all that the 4.3BSD "telnet" program
does is take the UNIX environment variable TERM, upper-casify it, and
use the result.  Unfortunately, UNIX doesn't tend to use the RFC1010
names; for example, the names it uses for VT100s are "vt100",
"vt100-am", and "vt100am", but not "dec-vt100" or its upper-case equivalent.

This works fine and dandy when one UNIX system talks to another, but if
somebody else out there implements precisely the recommendations of
RFC930 and RFC1010 their implementation may not recognize "vt100" as a
VT-100. 

I don't know if this is a serious problem (as I said, it works fine and
dandy for UNIX), or if it is what the correct fix is (the list of
terminals that UNIX, in some sense, knows about - e.g., the ones in the
"termcap" or "terminfo" data base - is much larger thatn the list of
terminals in RFC1010; for instance, I don't see an entry in that section
for "sun", but I'd be pretty cheesed off if, when I TELNETted to another
UNIX system from a window on my machine, it didn't understand that it
should set the TERM environment variable to "sun").  Perhaps it should
map to the "canonical" name if one exists, pass the non-canonical name
across the net otherwise (unless it conflicts with a canonical name for
some other terminal, in which case you have to do something else), and
hope for the best.... 

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 1988 18:46-EDT
From:      URBANIAK@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        Urbaniak@BBN.COM
Subject:   Ethernet Type Fields
Attached is the most recent list of Ethernet Type Fields, Vendor Addresses,
and known Multicast Addresses. please direct comments to Urbaniak@BBN.COM.

Some Known Ethernet and IEEE802.3 "Type" Fields		10/29/88

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

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation for IP
1600	VALID system protocol *
5208	BBN Simnet Private %
6000	DEC unassigned
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC)
6008	DEC unassigned
6009	DEC unassigned
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
8035	Reverse Address Resolution Protocol (RARP)
8038	DEC LanBridge Management
8039	DEC unassigned
803A	DEC unassigned
803B	DEC unassigned
803C	DEC unassigned
803D	DEC Ethernet Encryption Protocol
803E	DEC unassigned
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned
8041	DEC unassigned
8042	DEC unassigned
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
807C	Merit Internodal
8080	Vitalink TransLAN III Management
809B	EtherTalk (AppleTalk over Ethernet)
80C1	DCA Data Exchange Cluster
80DE	TRFS (Integrated Solutions Transparent Remote File System)
80F3	AppleTalk Address Resolution Protocol (AARP)
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8137	Novell (old)
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
FF00	BBN VITAL-LanBridge cache wakeups %

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

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

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

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

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

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

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

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

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0804	CHAOS
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	0BAD	Banyan
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
FF-FF-FF-FF-FF-FF	8035	Reverse ARP
FF-FF-FF-FF-FF-FF	807C	Merit Internodal (INP)
FF-FF-FF-FF-FF-FF	809B	EtherTalk
-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 88 20:16:27 GMT
From:      jordan@zooks.ads.com (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

Roy Smith <roy@phri.UUCP> writes:

	Given that the quantity is bogosity ...

Wasn't it Honeyman who pronounced Mark Horton's old machine (cbosgd)
as "See Bogosity" ...?

/jordan

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 88 22:17:28 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb question: ping w/o icmp support?

Henry,

As for Millstones as a measure of network bogosity, be advised a wag or two
seem to have preempted the term as a measure of gateway throughput. As in
your case, the units of measure, as well as the procedures of measurment,
are in dispute. The committee convened to settle the issues met in the corner
pub, became Millstoned and turned into a puff of hot air.

Boy, that was close.

Dave

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 88 22:46:00 GMT
From:      URBANIAK@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Ethernet Type Fields

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

 Some Known Ethernet and IEEE802.3 "Type" Fields		10/29/88

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

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation for IP
1600	VALID system protocol *
5208	BBN Simnet Private %
6000	DEC unassigned
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC)
6008	DEC unassigned
6009	DEC unassigned
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
8035	Reverse Address Resolution Protocol (RARP)
8038	DEC LanBridge Management
8039	DEC unassigned
803A	DEC unassigned
803B	DEC unassigned
803C	DEC unassigned
803D	DEC Ethernet Encryption Protocol
803E	DEC unassigned
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned
8041	DEC unassigned
8042	DEC unassigned
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
807C	Merit Internodal
8080	Vitalink TransLAN III Management
809B	EtherTalk (AppleTalk over Ethernet)
80C1	DCA Data Exchange Cluster
80DE	TRFS (Integrated Solutions Transparent Remote File System)
80F3	AppleTalk Address Resolution Protocol (AARP)
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8137	Novell (old)
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
FF00	BBN VITAL-LanBridge cache wakeups %

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

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

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

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

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

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

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

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

Broadcast Address:

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

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 88 09:05:52 GMT
From:      tasman@CS.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   Telnet Output Flushing Guidelines (long)


     A few years back, I along with Steve Dyer, Charles Lynn, and Dan
Tappan set out to rationalize output flushing in the various BBN
implementations of telnet over TCP/IP.  The systems involved were the
C/30 TAC (Terminal Access Controller), the C/70, DECSystem-20 (running
a BBN version of TOPS-20), and a home-grown terminal server called
a Fibrenet TC.  Dave Plummer and Jon Postel were also valuable sources
of advice.

    Because of the variety of implementations involved, we decided the
only practical approach was to use (what recent TCP-IP messages have termed)
an "open loop" scheme.  The telnet client does not attempt to identify
interrupt or flush characters; it simply passes them to the telnet
server.  It is the responsibility of the server to initiate an output
flush, if appropriate.

    Many operating systems have some character (or string or characters) 
which, when typed from a hardwired terminal, will cause output to be
flushed (i.e. discarded).  Presumably, receipt of this character (or
characters) causes a flush signal to be sent to the terminal driver,
which discards the contents of it's output buffer.  The particular
character (e.g. ^C, ^O, HX, etc.) is irrelevant.

    The job of the telnet server is to, upon receipt of a flush signal,
emulate the action of a hardwired terminal driver as closely as possible.
Herein lies the first caveat:  

		The telnet output stream contains embedded
		option negotations.  Output cannot simply be
		discarded, or option negotiations may be lost.
		Thus, even while a flush is in progress, the 
		telnet client still must scan the incoming stream
		for option negotiations; normal characters can be
		discarded.

     Upon receipt of a flush signal, the telnet server must as quickly as
possible notify the client that a flush is in progress.  This implies two
things:
	a) The notification should be attached to the very next TCP
	   segment sent to the client, even if there are several
	   thousand bytes of TCP data buffered at the server's machine.
	b) As soon as a TCP segment with a flush indication arrives at
	   the client's machine, the client should be signaled.  This
	   is true EVEN IF the TCP segment arrives out of sequence or
	   is a retransmission.  N.B.: The data contained in the segment
	   should NOT be presented out-of-sequence; the client simply
	   needs to know to begin flushing.
	
      Not surprisingly, this requires careful coding of the TCP 
implementations used by both the server and client; I'll address this
issue again toward the end of the message.

      So, how is this accomplished?  If the "URGENT" bit is set in a TCP
segment, the segment contains the identification of an "interesting" byte
in the data stream.  The sequence number of the "interesting" byte is
calculated as follows:

	sequence number = Segment Sequence Number + Urgent Pointer

WARNING WARNING WARNING:  Certain pages of the TCP Specification (both
			  RFC 793 and MILSTD 1778), as well as the Stallings
			  Handbook, state that this calculation yields the
			  sequence number of the byte FOLLOWING the
			  "interesting" byte.  This is WRONG.  Page 8 of the
			  latest "Official Internet Protocols" (RFC1011)
			  provides a clarification.  Please check your
			  implementation.			  

    Whenever the telnet server receives a flush signal, it inserts the two-
character sequence IAC DM in the outgoing data stream, and instructs its
TCP to mark the second character (DM) as "interesting".  Note that multiple
flushes are handled OK; outgoing TCP segments will always identify the latest
(e.g. highest-sequence-numbered) "interesting" byte identification.

    Action by the telnet client is fairly straightforward.  When an
"interesting" byte identification arrives at the telnet client's machine, the
client will be in one of two states:

	1) Processing incoming data normally.  The TCP implementation will
	   immediately notify the client that there is an "interesting"
	   byte somewhere ahead in the data stream, and the client will
	   enter state 2.
	2) Processing a flush (handling option negotiations, but discarding
	   normal data) until the "interesting" byte has been read and an
	   IAC DM sequence has been found.  The TCP implementation will
	   simply update its record of the "interesting" byte's sequence
	   number.  Thus two flushes in quick succession will be handled as
	   a single longer flush: the client will find the first IAC DM,
	   but discover that the "interesting" byte hasn't yet been read.

     Note that the preceding discussion assumes that:

	a) An "interesting byte" is read in-sequence.  If byte 101 is
	   "interesting", it will be read after bytes 99 and 100.  For
	   telnet, it's useless to be able to read the "interesting" byte
	   out-of-sequence.  Instead, the TCP implementation informs the
	   telnet client asynchronously that an "interesting" byte lies
	   somewhere ahead in the data stream.
	b) After a TCP read, the telnet client is able to inquire whether
	   the "interesting" byte has been read.  This is necessary so
	   that the client can determine when to stop flushing.

HINT:   Because of the specification error regarding the calculation of
	the sequence number of the "interesting" byte, some TCP implementations
	may incorrectly mark the byte FOLLOWING the DM as "interesting".  A
	strict interpretation of the telnet specification will result in the
	client flushing output forever, because the "interesting" byte will
	not yet have been read at the time the IAC DM is found, and the client
	will search forever for another IAC DM sequence. Thus, I recommend
	unconditionally terminating the flush after the "interesting" byte
	has been read, even if an IAC DM has not been located.  Your users
        will be a lot happier!

     	
     I previously mentioned that careful coding of the server and client
TCP's was necessary for optimal performance.  In particular, every TCP segment
sent by the server's machine should contain the latest "interesting"
sequence number.  If possible, this should even apply to retransmissions.
The client machine's TCP should immediately check all incoming segments for
updated "interesting" byte information.  The goal in both cases is to ensure
that the telnet client is notified of the flush absolutely as soon as possible.
These implementation guidelines become more critical as the TCP receive 
window size of the client is increased; the amount of TCP data buffered in the
server and client machines can become very large indeed!


Conclusions:     

     A LOT of work was involved, but our telnet project at BBN was largely
successful.  The improvement was dramatic for 300 Baud terminals, but even
at 9600 baud the reduction in output (after sending a character which
resulted in a flush) was quite noticable when displaying short lines.

     I've been planning to write an RFC on the subject of TCP URGENT
and its use with telnet; given the sudden flurry of interest, perhaps
now would be a propitious time.  An expanded (and more coherent!) version
of this message may someday appear.

     Best of luck.

					Mitchell Tasman
					University of Wisconsin-Madison
				    and BBN Communications Corporation

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 88 15:17:27 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP terminalservers and BREAK(/^C)


From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
>Just a curiosity?  Why does EMACS use a ^O to create a new line?  It would
>seem that the existing ENTER and RETURN keys should work fine; however, it
>does point out a need for the host and terminal servers to have some mechanism
>for establishing what are significant keys and their implications.

Well, I won't go into defending the choice of key (I believe the
mnemonic was "Open line", perhaps that's satisfying? Its actions are
usually not identical to ENTER/RETURN, typically moving the cursor to
the beginning of the line and opening above or below, ENTER would just
break the line wherever the cursor was at the moment into two lines,
not open a "fresh" line.) Hmm, guess that was a defense :-)

As far as "significant keys", one could adapt something like
'termination masks' from other OS's (TOPS-20 and VMS both have
facilities sort of like this I believe but less ambitious.)

Say you list all significant functions as values:

define	TEXT		00	# Echo locally (or might be an or'd in bit)
define	TERMINATE	01	# Send everything buffered or just this char
define	INTERRUPT	02	# like ^C
define	STOPFLOW	03	# like ^S
define	STARTFLOW	04	# like ^Q
define	TOGGLEOUTPUT	05	# like ^O toggle
	..etc..

and so on and decide there are about 16 or less of them (whatever) so
they can be encoded in a 4-bit nibble. Then you create a table of 256
of these (128 bytes) with an entry from the above in each position.

Then the client side can use this table to drive how to handle each
character and the server side can pass updated tables whenever
something changes.

Although passing 128 bytes is more or less like passing any packet
(that is, due to packet overhead making the table much smaller doesn't
save much bandwidth, I could argue that with a few of the following
efficiencies you may as well make it 256 bytes and make the management
and lookup easy on byte oriented machines) one can imagine a few
commands like "just change position 27 to a TERMINATE" or
"TERMINATE+NOECHO ON ALL" to exploit, only a few of those would be
needed to drastically cut down on having to exchange the masks very
often I would guess since most O/S's have similar global commands (go
into RAW mode.)

Now the main challenge left would be to define a set of mask values
everyone can live with (it should be do-able since at worst you send a
TERMINATE+NOECHO ON ALL and have what you have today.)

	-Barry Shein, ||Encore||

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 88 15:57:55 GMT
From:      sow@eru.mt.luth.se (Sven-Ove Westberg)
To:        comp.protocols.tcp-ip
Subject:   Telnet window size.


I would be very pleased if someone could mail me patches
to BSD4.3 telnet and telnetd for the "Telnet window Size Option".

Regards,

Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Internet: sow@cad.luth.se
UUCP:    {uunet,mcvax}!enea!cad.luth.se!sow
ARPA:    sow%cad.luth.se@ucbvax.berkeley.edu  (only dumb ARPA mailers)
Bitnet:  sow%cad.luth.se@sekth

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 88 16:43:49 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  up-to-date RFC/protocol index?

As of Saturday, 29 OCT 88, the current "Official Arpanet Protocols" by
Reynolds and Postel is RFC1011 published MAY 87.  It is available via
anonymous FTP from SRI-NIC.ARPA as RFC:RFC1011.TXT.  You may also want
to get RFC:RFC-INDEX.TXT which is the list of all RFCs that have been
published up to OCT 88.  The latest in the list is RFC1073.  Several of
the RFCs supercede or update those listed in RFC1011.

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 88 21:21:15 GMT
From:      pgg@GATEWAY.MITRE.ORG (Mail account)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP test suites

>  Date: 26 Oct 88 04:35:00 GMT
>  Subject: TCP/IP test suites
>  
>  We wish to conduct conformance testing of our TCP/IP implementation,
>  and as such, we would like to obtain an appropriate protocol test
>  suite.  ...
>  
>  Please e-mail replies to the address below.


I'm sure there are many folks who would be interested in seeing the 
replies to this request.  I encourage those who respond to cc the full 
tcp-ip mailing list in addition to replying to the requester.  Thanks.

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 88 23:36:46 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)

Michael Patton <map@gaak.lcs.mit.edu> writes...
> Except that the client end can't possibly have enough information
> about what is and isn't going to cause output to be flushed, only the
> server end (and maybe the user if they know the insides of the server)
> can know that.  You can't expect a user to type magic commands
> frequently so for this scheme to work you need to add new options in
> TELNET to allow the server to tell you every time this changes.

I surely agree with this...

> These will have the same implementation problem that GA had (see parallel
> discussion) where the server process can't get at the information.

But not with this.  Yes, with many present implementations a telnet server
can't get the necessary information from the user process or terminal driver
or whatever.  But once there's a mechanism for using the information,
mechanisms will be developed (operating systems will be modified) to make it
available where necessary.  Cray and Encore at least, and probably others,
have already done this in different ways.  4.3BSD "almost" does it (by providing
a way to switch off the terminal driver in a pseudo-tty, but don't think they
have any way to notify the server of application-initiated changes;
I haven't seen 4.3-tahoe though).

> All in all, I think this suggestion only makes the problem harder to
> solve right.  Given the underlying TCP functionality, I think the
> original Abort Output (AO) is the best we're going to do, except for
> the problem of implementing it in some cases.

Aw, give it a chance!  This is a classic chicken vs. egg problem, might as
well allow a few species of birds to evolve before predicting we'll never
taste an omelet.  Though I'll agree to the extent that we need to leave
room in our diet for those reptilian operating systems that lack paths
for the necessary information... but that's what negotiations are about.

	Stuart Levy, Minnesota Supercomputer Center
	slevy@uc.msc.umn.edu

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 00:02:50 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Copyrighted messages

Van,

With all due respect and sympathy for trade-rag misquote, I would
like very much to dissuade anybody using these widely read distribution
lists from copyrighting messages. Interpreted narrowly, they can't be
replied to (copyrighted header), forwarded to a student, archived or
duplicated, electronically or otherwise. The tcp-ip list itself has
a duplication policy which has been explicitly repeated from time to
time (can this be done again, please) for exactly the reason that
caused your pique. While I can paraphrase that policy here, I would
rather the NIC resend the exact wording.

Meanwhile, if you must copyright anything sent to this or other electric
reproduction machine, please specify exactly your interpretation of fair
use; that is, whether reproduction is permitted electronically, on paper,
whether the header is included and whether limited reproduction is
permitted for educational purposes. I would assume that, legally, this
specification would have to appear on every message.

Dave

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Oct 88 09:13:21 EST
From:      David Matthews-Morgan <DMM%UGA.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   System V Name Servers
Thanks to all who responded to my inquiry about domain name servers for
System V.  It is my understanding that Lachmann Associates and Wollongong
have developed networking software which supports name servers.
         David Matthews-Morgan
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Oct 88 10:36:41 EST
From:      "Lorraine A. Silber" <lsilber@cct.bbn.com>
To:        tektronix!orca!hammer.dougg@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa
Cc:        lsilber@cct.bbn.com
Subject:   TCP-/IP Test Suite
Doug --

BBN Communications offers a service called Test Net that provides X.25
(CCITT and DDN), TCP/IP, and higher-level protocol testing.  

We offer conformance testing of X.25 now and hope to be accredited to certify
X.25 implementations for DDN by the end of November.  TCP/IP conformance
testing is a more difficult matter.  The only conformance test suite for TCP/IP
that I know about was developed by UNISYS under contract to Defense
Communications Agency.  It is to be used to test TCP/IP implementations for
DDN, but it has not been released to any laboratory to do TCP/IP certifications
as yet, although I have heard it will be used next year.  There has been much
discussion about this test suite, and one of the difficulties about it is that
it was developed to run on a microvax using Ultrix 1.1, an obsolete operating
system.  I believe the test suite is available from the government now, but I
don't have any more details on how you can receive it.

Test Net can offer you functional, performance, and interoperability testing of
TCP/IP and any higher-level protocols your product may have.  We offer
real-life network testing and a realistic, multi-vendor network environment.
Our test network is a part of the BBNNet, and we can connect your product to it
in our lab or via a dial-up connection from your site.  Using a test plan
customized for your product, we can use special test tools to stress your
product and find problems.

If you would like more information on Test Net, please contact me.  I would be
happy to explain our services further.

Lori Silber                      
lsilber@cct.bbn.com
BBN Communications Corporation
703-848-4855


-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 05:48:28 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Mistakes...

Shane,  You are too sensitive. But, heck, that's not really a deep criticism.

You simply lack the 'culture" of mailing list behavior.  Not that the 
current culture is good or bad, but it just "is".  I have noted for the past
half decade that many persons who send out postings have this cutesy hack
that let's them have an arbitrary "quote of the day". I liken it to those
silly yellow diamonds on the back of many automobiles that say things
like "Baby on Board" or "Honk if you love Brakes".  IN other words
most of society regards that kind of "statement" as rather innocuous.
I think the ssame goes for the signoffs on mailing lists and such.

Just ignore it and hope others ignore yours...

Welcome aboard!

Dan
-------

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Oct 88 11:03:38 EST
From:      jam@radc-lonex.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   copyrights
> Van,
> 
> With all due respect and sympathy for trade-rag misquote, I would
> like very much to dissuade anybody using these widely read distribution
> lists from copyrighting messages. Interpreted narrowly, they can't be
> replied to (copyrighted header), forwarded to a student, archived or
> duplicated, electronically or otherwise. The tcp-ip list itself has
> a duplication policy which has been explicitly repeated from time to
> time (can this be done again, please) for exactly the reason that
> caused your pique. While I can paraphrase that policy here, I would
> rather the NIC resend the exact wording.
> 
> Meanwhile, if you must copyright anything sent to this or other electric
> reproduction machine, please specify exactly your interpretation of fair
> use; that is, whether reproduction is permitted electronically, on paper,
> whether the header is included and whether limited reproduction is
> permitted for educational purposes. I would assume that, legally, this
> specification would have to appear on every message.
> 
> Dave
> 

Uh, excuse me, but don't all copyrights have to be registered with the US
government within a specific amount of time?  And of course if we
reported every mail item we ever sent, they would probably have to allocate
the defense budget, welfare, social security, and just about everything
else to hire enough clerks in the copyright office!

On the serious side, copyrighting a mail item prohibits the retransmission
or copying of the item, electronically or otherwise (which makes it awfully
hard to reply to in this forum).  But I don't think that it prevents you
from being quoted (or misquoted), as long as the person doing that provides
an appropriate bibliography.

Joel
-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 06:06:26 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   CMU and WIN not talking, ideas?

Just incorporated TCP/IP packages on two VMS 4.6 MicroVAX IIs.  They are now
DEQNA to DEQNA (FCO looks current).  DECNET (FULL to END) works.  We are try-
ing to get them running but don't yet have external Internet or other hosts to
talk to.  Each currently can do loopbacks ( me, myhostname, myhostnumber ) but
both CMU 6.3 and WIN_TCP 3.2 complain of timeout.  Yes DECNET was started FIRST.

Both products were installed by the book.  They only fail when attempting to
talk OFF-HOST.

Would anyone care to suggest some tips to troubleshoot this problem .. no 
third ethernet device .. no network analyzer.  Ideas greatly appreciated

/Ev/
-- 
           The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
    efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 08:55:25 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)

In regard to telnet `virtual terminal driver' mode:

Michael Patton <map@gaak.lcs.mit.edu>:
>... implementation problem ... where the server process can't
>get at the information.
	
Stuart Levy <slevy@uc.msc.umn.edu>:
>... once there's a mechanism for using the information, mechanisms will
>be developed (operating systems will be modified) to make it available
>where necessary.

Agreed; I think that a `virtual terminal driver' would work well, provided
(alas!) it matches well with existing terminal drivers (and there are so
many that this is likely to be difficult).

>4.3BSD "almost" does it ... don't think they have any way to notify the
>server of application-initiated changes; I haven't seen 4.3-tahoe though.

The only way for a server to find out about changes would be for it to
poll the pty driver continuously, which is not workable for the obvious
(I hope it is obvious!) reason.  But fixing this would take only a few
lines of code.

>This is a classic chicken vs. egg problem, might as well allow a few
>species of birds to evolve before predicting we'll never taste an omelet.

But will we end up with the electronic equivalent of hardening of the
arteries?  :-)

Chris

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 14:13:21 GMT
From:      DMM@UGA.BITNET (David Matthews-Morgan)
To:        comp.protocols.tcp-ip
Subject:   System V Name Servers

Thanks to all who responded to my inquiry about domain name servers for
System V.  It is my understanding that Lachmann Associates and Wollongong
have developed networking software which supports name servers.
         David Matthews-Morgan

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 15:05:19 GMT
From:      ZREN@DS0RUS1I.BITNET (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Reliable Datagrams

Ok. they are unreliable and nonreliable.(checksum only for header!).

Michael.

 ------------------------------------------------------------------
    Address:                            Local Office:
 Cray Research GmbH                    Cray Research Software Office
  Michael Nittmann                       Michael Nittmann
 Networking Support                  c/o
                                              RUS
 Kistlerhofstr. 168                  UNIVERSITY OF STUTTGART
    8 Munich 71                          Allmandring 30
     Germany                              7 Stuttgart 1
                                            Germany
 E-mail and reply to:                      Phone:
 UG051%CRAYAMID.CRAY.COM@UMN-REI-UC.ARPA   0711/6855847 or 0711/6874767
Acknowledge-To: <ZREN@DS0RUS1I>

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 15:36:41 GMT
From:      lsilber@CCT.BBN.COM ("Lorraine A. Silber")
To:        comp.protocols.tcp-ip
Subject:   TCP-/IP Test Suite

Doug --

BBN Communications offers a service called Test Net that provides X.25
(CCITT and DDN), TCP/IP, and higher-level protocol testing.  

We offer conformance testing of X.25 now and hope to be accredited to certify
X.25 implementations for DDN by the end of November.  TCP/IP conformance
testing is a more difficult matter.  The only conformance test suite for TCP/IP
that I know about was developed by UNISYS under contract to Defense
Communications Agency.  It is to be used to test TCP/IP implementations for
DDN, but it has not been released to any laboratory to do TCP/IP certifications
as yet, although I have heard it will be used next year.  There has been much
discussion about this test suite, and one of the difficulties about it is that
it was developed to run on a microvax using Ultrix 1.1, an obsolete operating
system.  I believe the test suite is available from the government now, but I
don't have any more details on how you can receive it.

Test Net can offer you functional, performance, and interoperability testing of
TCP/IP and any higher-level protocols your product may have.  We offer
real-life network testing and a realistic, multi-vendor network environment.
Our test network is a part of the BBNNet, and we can connect your product to it
in our lab or via a dial-up connection from your site.  Using a test plan
customized for your product, we can use special test tools to stress your
product and find problems.

If you would like more information on Test Net, please contact me.  I would be
happy to explain our services further.

Lori Silber                      
lsilber@cct.bbn.com
BBN Communications Corporation
703-848-4855

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 16:40:58 GMT
From:      lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip terminal servers

> Date: 27 Oct 88 06:22:53 GMT
> From: suned1!efb@elroy.jpl.nasa.gov  (Everett F. Batey II)
> Organization: NSWSES, Port Hueneme, CA
> Subject: Re: tcp-ip terminal servers
> References: <337@thor.wright.EDU>, <417@wasatch.UUCP>
> 
> MY QUESTION.  We are on a site with a 192... address assigned.  That is across
> a MILnet gateway.  To use my telnet / rlogin servers, must I consume some of
> those 254 addresses? 

A terminal server is a HOST, albeit a somewhat specialized one (i.e. it does
perform all kinds of host services). A host must have an IP address.
If your ethernet has a network number, the host must have an address
with the address space of that network.

Why would you (a) not want that ?
	      (b) think this could be otherwise ?

> Is there a network legal way to be on another net number
> in the 255.255.255. upper 24 bits?  Which my local hosts can see and still
> get helped NS from my local domain internal name server?

A terminal server does not have to be on the same network as the hosts
it is communicating with. I.e. if your terminal server is on an ethernet
connected to Milnet with a proper gateway, it can communicate with any
host on the combined Internet, i.e. not just with your local machines
but with any machines attached to MILnet, any machines attached to
ARPAnet, any machines attached to NSFnet, any machines attached to
the MIT campus net, etc. This is why we have IP in the first place.

Thus, if you have multiple networks, you can attach terminal servers
to whichever network you want, and they will still get to wherever
you want to get to.

However, it is a feature of IP routing, that when your packets move from
one net to another, they do so at an IP gateway. Thus, you are imposing
a processing load on the gateway node. This is not altogether desirable
if the reason you moved the terminal ports off the bigger host in the
first place was to save processing cycles on the bigger host.

The location of your terminal server with respect to the name server
is a slightly different issue. If the terminal server uses standard
DOMAIN protocol, this runs on top of IP, so you can get name service
from any host on the combined internet that has access to the information
for your domain; however, you will usually (for reasons of performance
and overhead avoidance) want to get it from a host as close to the terminal
server as possible.
 
> WHAT does every one else with multiple hosts and servers on a local ethernet
> gatewayed to ARPA / Internet do to preserve host addresses with servers?
> ...
>     efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa

Numbers are fairly cheap. If you are planning to connect more than 254 hosts
(including PCs an terminal servers) to your local network, then you should
get a class B network instead of a class C network. This is MUCH friendlier
to the world than to have multiple class C networks behind a gateway.

	/ Lars Poulsen
	  ACC Customer Service
	  Advanced Computer Communications

	("We make advanced computers communicate")

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 18:02:00 GMT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: telnet v.s. rlogin



    From:  hedrick at ARAMIS.RUTGERS.EDU (Charles Hedrick)
    
    systems actually make this distinction.  (Many systems represent end
    of line in files in different ways, but that's not the issue.  The
    issue is whether what comes from the terminal when the user wants to
    generate an end of line is CR.)
    going to be treated the same, and it is hard to see why the telnet

Actually, that's a little simplistic since the definition of EOL, while
in the TELNET spec, is actually part of the Network Virtual Terminal
(NVT) definition.  Note that NVT is not only used in TELNET but in other
protocols as well such as FTP where the EOL character that is used
inside a file is very important for the correct transfer of files between
heterogeneous file systems.

                              John G. Ata

    

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 19:07:26 GMT
From:      todd@SEAS.UCLA.EDU (Todd Booth)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS over TCP/UDP

In article <187@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>OK, my next question is "what is the purpose of NetBIOS over TCP" ?
>I see two answers:  (1) To take the existing horde of NetBIOS
>applications and run them on other systems;  (2) To provide another
>communication interface for a programmer.

There's a more important reason.  

> (1)

A NetBIOS over TCP interface isn't required to run NetBIOS on other
systems.  Any NetBIOS interface can do that.

> (2)

NetBIOS over TCP doesn't provide a new communication interface to the
programmer.  If implemented correctly, the NetBIOS interface should
look the same if it runs on top of ISO Network, TCP, IP, LLC, IPX,
XNS, ...   The whole point of a standard interface (NetBIOS) is to
shield the programmer from the details of the lower layers.  

I see the advantage of NetBIOS over TCP/IP as the ability to provide
NetBIOS with an reliable data stream over an IP based network.

>It seems I'm missing something in the reasoning behind wanting
>NetBIOS over TCP, but given that vendors exist that sell this as a
>product there must be a need for it.  Can someone shed some light on
>just what people are doing with it ?  Thanks.

Don't know what's being done, but here's one example of what can be
done:

Simtel is a real pain for new users to access files via FTP.  Simtel
could run one of the PC DOS based network operating systems that 
require NetBIOS, for example IBM's PC LAN Program.  They could use a
NetBIOS over TCP/IP interface and develop a custom DOS application
which provides uses a menu front end to retrieving their existing
files.  This would allow other NetBIOS over TCP/IP users throughout
the internet to have a menu front end to the Simtel directories, in
full color, with optional help keys, file definitions, automatic file
downloading (note that FTP would no longer be required).  In other
words the ease of use of typical PC applications with the
communications capabilities of TCP/IP.

Disclaimer: I know very little about the NetBIOS over TCP/IP standard,
jsut a few things about layered network architechure.

--todd booth / ucla data communications

ArpaNet      todd@seas.ucla.EDU
UUCP         {ihnp4,ucbvax}!ucla-cs!todd
Voice        +1 (213) 825-1933
BitNet       csdctgb@uclamvs.bitnet

--todd

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 20:11:25 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: telnet v.s. rlogin

As far as I know, no one has implemented RFC 1053 to date, not even me.
*If* enough functionality comes to be added to IDEA 16, it may be a moot point.

The CR-NUL vs. CR-LF problem is dealt with in the pending Host
Requirements RFC by specifying that hosts should be prepared to accept
either.  That seems adequate, doesn't it?

	Stuart Levy, slevy@uc.msc.umn.edu

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 21:37:25 GMT
From:      parker@waters.mpr.ca (Ross Parker)
To:        comp.protocols.tcp-ip
Subject:   SLIP installation

There was recently an article in this newsgroup written by someone who
had sucessfully installed SLIP on an Ultrix workstation. I am currently
trying to install SLIP on a Microvax-II running Ultrix 2.0, and am running
into problems. I would appreciate hearing what modifications were necessary
for Ultrix. I have installed everything correctly as far as I can see
(modifications were definitely necessary for Ultrix), but am getting:

	/dev/ttyxx: No such device or address

when I try the slattach.

Any pointers would be appreciated!

Thanks!

Ross Parker      uunet!ubc-cs!mpre!parker       |
Microtel Pacific Research Ltd.			| You can't erase the dream,
Burnaby, B.C.,					| you can only wake me up...
Canada, eh?					|

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Oct 88 21:52:28 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

In article <3575@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>	Given that the quantity is bogosity, and the universe in which this
>quantity exists is the swamp, it seems that "the bog" is the obvious name for
>the unit of measure...

Best suggestion I've heard so far.  There have been a few truly interesting
ones by private mail, but the better ones are unprintable.  (Among the
also-rans are the "Berkeley", the "ATTIS", and the "Sun".)  The "Millstone"
is already spoken for, alas:  it's the unit of gateway throughput! :-)

>Next question; do we define a fixed goodness-to-badness
>continium with 1 bog being totaly bogus (thus, a 10 decibog box would be 90%
>in compliance with the specs) or do we define an open-ended scale, on the
>assumption that no matter how bad something is, somebody will always manage
>to come along with something worse?

"Decibog" sounds clumsy.  I'd propose that the main scale runs from 0 to 10
bog, with higher (and negative) ratings reserved for exceptional cases.
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 22:22:00 GMT
From:      stanonik@NPRDC.ARPA (Ron Stanonik)
To:        comp.protocols.tcp-ip
Subject:   4.3bsd imp going down crash?

Our vax 11/780 running 4.3bsd with an lhdh crashed shortly
after "imp going down" and "imp marked down" messages.  The
error was a seg fault and as I read (or misread) the crash
dump, the "marked down" message cleared the per imp hosttable
(sc->imp_hosts) while impstart was trying to read it (actually
impstart had handed the value to impstarthost, which is where
we croaked).

Does this sound familiar; ie, have we missed some bug fix?
We are running the networking fixes that berkeley announced
a while ago; eg, if_imp.c is version 7.5 6/8/88.

Thanks,

Ron Stanonik
stanonik@nprdc.arpa

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 88 22:55:07 GMT
From:      KLH@SRI-NIC.ARPA (Ken Harrenstien)
To:        comp.protocols.tcp-ip
Subject:   SUPDUP (was: telnet vs rlogin)

For several days now people have been talking about whether TELNET can
support Unix notions like rlogin, and if so, how.  Groan.  Wheel
re-invention is always discouraging to see, especially when the new is
worse than the old; I'm not sure if this message will help, but I feel
obliged to speak up.

There have already been several attempts to enhance TELNET
negotiations to support the exchange of terminal type/handling
information and to encourage transparency.  The most successful that
I'm personally aware of -- certainly one of the oldest -- is SUPDUP.

SUPDUP is listed as one of the TELNET options in the DDN Procotol
handbook; unfortunately, for full details it refers to another RFC
which by some oversight is not included in the handbook.  I have
listed the relevant RFCs below:

(RFC749)
   NIC-45499    18 Sep 78    (Greenberg)   Telnet SUPDUP-OUTPUT Option
(RFC747)
   NIC-44015    21 Mar 78    (Crispin)     Recent Extensions to the SUPDUP 
   Protocol
(RFC746)
   NIC-43976    17 Mar 78    (Stallman)    The SUPDUP Graphics Extension
(RFC736)
   NIC-42213    31 Oct 77    (Crispin)     TELNET SUPDUP Option
(RFC734)
   NIC-41953     7 Oct 77    (Crispin)     SUPDUP Protocol

These (or any other) RFCs can be obtained from SRI-NIC.ARPA either by
FTP of the filenames RFC:RFCnnn.TXT or by e-mail to
SERVICE@SRI-NIC.ARPA with "RFC nnn" in the subject line.  The index
itself is RFC:RFC-INDEX.TXT (or "RFC INDEX").

--Ken
-------

END OF DOCUMENT