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 May 1988 (403 messages, 186148 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 May 88 02:06:56 GMT
From:      fair@UCBARPA.BERKELEY.EDU (Erik E. Fair)
To:        comp.protocols.tcp-ip
Subject:   ARPANET charging schemes and which protocols are affected?

Does anyone have any hard numbers that document which application
protocols are used most over ARPANET (i.e. what TCP & UDP port
numbers are seen most often)? It'd be nice if these numbers included
both numbers of packets, and number of bytes (since FTP packets
are likely to be larger than TELNET packets).

The last time I saw any numbers for any part of the Internet,
numbers of packets were split: SMTP 30%, FTP 30%, TELNET 30%, and
OTHER 10% (this is from memory, so don't take the percentages too
literally - it was the relationship between them that I was concerned
about at the time).

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1 May 88 23:38 CDT
From:      LIVINGSTONE <@vms3.macc.wisc.edu:LIVINGSTONE@BERT.DecNet>
To:        TCP-IP@SRI-NIC.arpa
Subject:   Re: New BSD TCP/IP & Mt. Xinu
UNSUBSCRIBE TCPIP
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 May 88 19:24:28 GMT
From:      bernhold@qtp.ufl.edu (David E. Bernholdt)
To:        comp.protocols.tcp-ip
Subject:   Re:  Simple Cost Accounting Policy

In article <8804291239.AA21630@jvnca.csc.org> heker@JVNCA.CSC.ORG (Sergio Heker) writes:
>Thus I suggest 
>the fix cost depending on line bandwidth (as I recall Craig Partridge 
>suggested this before).

It seems to me that in the long run this is going to be a problem.  If
sites are charged based on the bandwidth of their connection to the
net, most bean-counters aren't likely to be overly generous with the
capacity they are willing to fund.  Then nobody is going to have the
bandwidth for any more than their own usage & nobody will be willing to
sacrifice their much-needed bandwidth to pass somebody else's packets
on to another destination.  And very quickly the net looses its
usefulness.

Is my view overly simplistic or too pessimistic (sp?)??  
Dave


-- 
David Bernholdt			Internet: bernhold@orange.qtp.ufl.edu
Quantum Theory Project		BITnet:   bernhold@ufpine.bitnet
University of Florida		HEPnet:   43129::59410::bernholdt
Gainesville, FL  32611		Phone:    904/392 9306

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      2 May 1988 08:03:38 CDT
From:      Link@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LINK@GUNTER-ADAM.ARPA
Subject:   Networking Classes

	I've got a new employee who's never done any networking before.  
I'm looking for some good classes for her.  I'd like the following topics
to be covered:  the OSI model, the Internet Community, the DOD model,
the MIL-STDs, Ethernet (802.3...), Gateway mechanisms, and an emphasis
on local networks.  Please reply directly; I no longer monitor TCP-IP.
Thanks.


  |====================================================================|
  |  Link Verstegen                Network Solutions, Inc. (NSI)       |
  |  Lead Hardware Engineer        4350 Will Rogers Parkway, Suite 100 |
  |                                Oklahoma City, OK  73064            |
  |  Link@Gunter-Adam.ARPA         (405)942-8884                       |
  |====================================================================|

-------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 02 May 88 10:57:16 EDT
From:      Ross Patterson <A024012%RUTVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Another problem with usage charges
>Well -- if you read the spec, FTP itself implements checkpoint/restart.
>Better protocols may be desirable, but for now we should make the most
>of the ones we already have.
>
>Has anyone implemented checkpoint/restart in FTP?

    Yup.  The UCLA TCP/IP for IBM's  MVS system, known as the "ARPANET
Control Program", or ACP, supports FTP checkpoint/restart.  The Unixes
we've got around here dont, since they won't accept a "MODE B" command
(Sun's  responds "Sorry,  only  stream mode  supported" (or  something
close to  that)).  ACP  is the  basis for  most, if  not all,  IBM MVS
implementations.   It supports  restarting  of  both transmission  and
reception,  as well  as allowing  the user  control over  the interval
between checkpoints (defaulting to 100K bytes).

    Are there any other checkpointers out there?

Ross Patterson
Rutgers University
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 May 1988 14:30:52 CDT
From:      AFDDN.BEACH@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        AFDDN.BEACH@GUNTER-ADAM.ARPA
Subject:   EDI (ANSI X12) use in the internet
To any who may know:
   Can anyone tell me if they're exchanging EDI formatted data across the
DoD internet using any of the TCP/Ip protocols?  I'm not the least
familiar with EDI so if anyone feels like clueing me in, have at it.  i
do seem to remember something about EDI and TOP being related.  Maybe I'm
just confused.  I'd appreciate any enlightenment anyone can throw
my way.
Thanks,
Darrel Beach
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 May 88 16:31 PDT
From:      Dale Smith <DSMITH@oregon.uoregon.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   potential problems with TTL = 0
What is the current "correct" value to place for the TTL field?  Can
someone with a Sequent Balance 21000 verify what the initial TTL value
is for TCP, UDP, and ICMP packets?

The reason for this query is that I am having problems delivering mail
to uunet.uu.net which is a Sequent Balance 21000.  I have observed TCP
packets from uunet.uu.net being dropped by my gateway because the TTL
was 0.  This seems to only happen for TCP traffic.  I can ping uunet and
get response of 1-2 seconds.  I can use nslookup to query uunet.uu.net
using datagram (UPD) mode.  However, use of any TCP based service to
uunet causes lots of TCP packets from uunet to be dropped at my gateway
with TTL = 0.  I have captured and looked at the UDP and ICMP packets
from uunet and they have different, but adequately large TTL values.
The folks at uunet say they are running some beta version of TCP/IP.

So, is there anyone out there from Sequent who can verify that this is
or is not a known problem?  Can someone with a Balance 21000 who is
running beta-version TCP software look at what the initial TTL value is?

Thanks,

Dale Smith, Assistant Director of Network Services

Internet: dsmith@oregon.uoregon.edu
BITNET:	dsmith@oregon.bitnet
Voice:	(503) 686-4394
USmail:	University of Oregon
	Computing Center
	Eugene, OR  97403-1212
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 13:03:38 GMT
From:      Link@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Networking Classes


	I've got a new employee who's never done any networking before.  
I'm looking for some good classes for her.  I'd like the following topics
to be covered:  the OSI model, the Internet Community, the DOD model,
the MIL-STDs, Ethernet (802.3...), Gateway mechanisms, and an emphasis
on local networks.  Please reply directly; I no longer monitor TCP-IP.
Thanks.


  |====================================================================|
  |  Link Verstegen                Network Solutions, Inc. (NSI)       |
  |  Lead Hardware Engineer        4350 Will Rogers Parkway, Suite 100 |
  |                                Oklahoma City, OK  73064            |
  |  Link@Gunter-Adam.ARPA         (405)942-8884                       |
  |====================================================================|

-------

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 14:57:16 GMT
From:      A024012@RUTVM1.BITNET (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: Another problem with usage charges

>Well -- if you read the spec, FTP itself implements checkpoint/restart.
>Better protocols may be desirable, but for now we should make the most
>of the ones we already have.
>
>Has anyone implemented checkpoint/restart in FTP?

    Yup.  The UCLA TCP/IP for IBM's  MVS system, known as the "ARPANET
Control Program", or ACP, supports FTP checkpoint/restart.  The Unixes
we've got around here dont, since they won't accept a "MODE B" command
(Sun's  responds "Sorry,  only  stream mode  supported" (or  something
close to  that)).  ACP  is the  basis for  most, if  not all,  IBM MVS
implementations.   It supports  restarting  of  both transmission  and
reception,  as well  as allowing  the user  control over  the interval
between checkpoints (defaulting to 100K bytes).

    Are there any other checkpointers out there?

Ross Patterson
Rutgers University

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 17:01:50 GMT
From:      Robin@turbo.RAY.COM (Robin Alston)
To:        comp.dcom.lans,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   can someone recommend a book covering tcp-ip and nfs?


Can some kind soul or souls recommend book, books or papers that talk about
tcp-ip on the one hand and nfs on the other. It looks like I am going to be
implementing a port of nfs to some of our hardware and we have a source
based on the SGI 3000 series workstations (which our whole system is kind
of based on). I will be involved initially with the low level talking bits
and packets on the ethernet board first but migrating up to nfs soon after
that. We also intend to implement a multi-processor unix using nfs but
communicating tcp-ip on the normal system bus, any recommended reading here
might be useful too.

ta v mucho.

-- 
 -------------------------------------------------
# Whats worse than two MA drivers on a freeway?    #      Dr. Robin the REAL
# Answer: One Toronto driver                       #      SuperUser Atilla!
 -------------------------------------------------	  (617)-460-8225
	Robin@turbo.ray.com		.....!rayssd!turbo!Robin

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 May 1988 21:16-EDT
From:      CERF@A.ISI.EDU
To:        Link@GUNTER-ADAM.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Networking Classes
Send her to one of Dan Lynch's tutorial sequences - he just did a good one
in Washington, DC.

Dan runs Advanced Computing Environments out of Palo Alto, CA (on San Antonion
Roa). He can be reached as Lynch@ISI.EDU.

Vint Cerf
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 17:57:36 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Many things on ethernet together???


   Date: 29 Apr 88 19:38:16 GMT
   From: rayssd!turbo!Robin@gatech.edu  (Robin Alston)
   Organization: Raytheon Company, Marlborough MA

   My question is can this really work?
   Can XNS and TCP-IP share the same coax cable with no possible problems?
   Can we have our own domain (we really have no interest at this time in
   talking to our vaxes), while decnet has its own on the same cable?

There is no problem at all with this, Ethernet was designed with
exactly this type of thing in mind (of course ISO is different, but
can be made to coexist with a simple kludge).  We have one Ethernet
here that carries TCP/IP, XNS and ChaosNet (that I know of, I'm sure
there are others that nobody bothers to tell me about) at the same
time.  In fact the MicroVAX that I use as a workstation runs both
TCP/IP and ChaosNet on the same interface without any problem.  The
designers of Ethernet assumed there would be multiple higher level
protocols and provided a field in the Ethernet packet to say which one
it carried.  Any reasonable Ethernet driver should just calmly ignore
(maybe count) any packets with a type field it doesn't recognize.

	Michael A. Patton
	Network Manager
	Lab. for Comp. Sci.
	Mass. Inst. of Tech.

P.S. For those who don't know the kludge for coexistance mentioned in
the body, ISO replaces the Ethernet type field with a length field
which occupies the same bits.  Coincidentally Ethernet types are
illegal ISO lengths and vice-versa, this allows the software to tell
them apart, you could look at it as assigning ISO a large number of
Ethernet type codes, which they then select between to encode the
length of the packet.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 19:02:26 GMT
From:      davidsen@steinmetz.ge.com (William E. Davidsen Jr)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Many things on ethernet together???

You can put a LOT of still on one cable. The limiting factor is the
traffic, not the number of devices (until you reach the addressing
limit). I would not expect to see any trouble, and you can get software
for the VMS machines to enable sending SMTP mail to them.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 19:14:00 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

In article <218@turbo.RAY.COM>, Robin@turbo.RAY.COM (Robin Alston) writes:
>
> We have a bunch of SGI workstations currently running XNS over ethernet.
> We have just been informed that when we move into a new building at the
> end of May we will have to use a single ethernet cable for the whole
> building which includes many vaxen running VMS many many pc's with some kind
> of future-net link and many pc's with simple vax links.
>
> My question is can this really work?
> Can XNS and TCP-IP share the same coax cable with no possible problems?
> Can we have our own domain (we really have no interest at this time in
> talking to our vaxes), while decnet has its own on the same cable?

We have converted our ever growing network from our XNS to TCP.  Two years
ago, we had ~100 workstations, some VAXes, and other stuff, all on one
cable.  We used XNS almost exclusively, even on the VAXes.  We now have
lots more workstations, more VAXes (VMS, 4.2+XNS+TCP, 4.3+NFS), PC-clones
running TCP, many cables, routers (our own, of course), bridges,
microwaves, an APRANET connection (also, of course, our own box--please
forgive the commercial), using almost exclusively TCP/IP/UDP.  The
conversion was continuous; for most percentages n between 1 and 100, we
have had n% TCP and (100-n)% XNS, without trouble.

We also mix DECnet with TCP & XNS on the same cable, using IRIS's & VAXes
to gateway between TCP & DECnet.

We have been blessed with other, educational troubles.  For example,
consider what groups of IRIS 4D's running the UDP-broadcast version of
'dog' at >30 frames/sec do to 750's, which think anything more than 20
broadcast packets/sec is a catastrophic storm.

Vernon Schryver
Silicon Graphics
vjs@sgi.com    {decwrl,sun,pyramid,research,allegra,ucbvax}!sgi!vjs

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 19:30:52 GMT
From:      AFDDN.BEACH@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   EDI (ANSI X12) use in the internet

To any who may know:
   Can anyone tell me if they're exchanging EDI formatted data across the
DoD internet using any of the TCP/Ip protocols?  I'm not the least
familiar with EDI so if anyone feels like clueing me in, have at it.  i
do seem to remember something about EDI and TOP being related.  Maybe I'm
just confused.  I'd appreciate any enlightenment anyone can throw
my way.
Thanks,
Darrel Beach
-------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 May 88 23:31:00 GMT
From:      DSMITH@OREGON.UOREGON.EDU (Dale Smith)
To:        comp.protocols.tcp-ip
Subject:   potential problems with TTL = 0

What is the current "correct" value to place for the TTL field?  Can
someone with a Sequent Balance 21000 verify what the initial TTL value
is for TCP, UDP, and ICMP packets?

The reason for this query is that I am having problems delivering mail
to uunet.uu.net which is a Sequent Balance 21000.  I have observed TCP
packets from uunet.uu.net being dropped by my gateway because the TTL
was 0.  This seems to only happen for TCP traffic.  I can ping uunet and
get response of 1-2 seconds.  I can use nslookup to query uunet.uu.net
using datagram (UPD) mode.  However, use of any TCP based service to
uunet causes lots of TCP packets from uunet to be dropped at my gateway
with TTL = 0.  I have captured and looked at the UDP and ICMP packets
from uunet and they have different, but adequately large TTL values.
The folks at uunet say they are running some beta version of TCP/IP.

So, is there anyone out there from Sequent who can verify that this is
or is not a known problem?  Can someone with a Balance 21000 who is
running beta-version TCP software look at what the initial TTL value is?

Thanks,

Dale Smith, Assistant Director of Network Services

Internet: dsmith@oregon.uoregon.edu
BITNET:	dsmith@oregon.bitnet
Voice:	(503) 686-4394
USmail:	University of Oregon
	Computing Center
	Eugene, OR  97403-1212

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 01:16:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Networking Classes

Send her to one of Dan Lynch's tutorial sequences - he just did a good one
in Washington, DC.

Dan runs Advanced Computing Environments out of Palo Alto, CA (on San Antonion
Roa). He can be reached as Lynch@ISI.EDU.

Vint Cerf

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 13:02 EDT
From:      Corrigan @ DDN3.ARPA
To:        tcp-ip @ sri-nic.arpa
Subject:   FTP Checkpoint
The FTP implementation on the Honeywell mainframe done for the World-Wide
Military Command and Control System (WWMCCS) implements and uses checkpoint/
restart.  It also lets you begin a transfer, leave, and check back later on 
status.  They used to move huge files in the mid/late 70's and restart was
essential for operational, not cost, reasons, because the system didn't stay
up long enough to complete very many transfers.  The checkpoints were based o
time, not number of records transfered, because the variability in throughput
was high, and minimizing the amount of lost time was the important issue.  I
think 5 minutes between checkpoints was the default.
  All this continues to work as we speak -- of course the protocol it is 
running over is NCP......

Mike

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 14:05:57 GMT
From:      rdt@teddy.UUCP (Ron D. Thornton)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP for Dec RT11 or DG RDOS

Process Software Corp has a version of TCP/IP for RT-11 SJ, FB, or XM.
While I did have a different opinion about what constituted bugs (broadcast
storms and static host names in the arp table) they have improved the
product and it does fit on an RT-11 system.

Process Software - Amherst, MA - (413) 549-6994

	-Ron-

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 14:35:52 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: can someone recommend a book covering tcp-ip and nfs?

Robin,  You should read Doug Comer's new book on TCP/IP.  "Internetworking
with TCP/IP, Prentice Hall, ISBN 0-13-470154-2.

And, you should come to Monterey next Monday to attend
a two day seminar on TCP Performance taught by Van Jacobsen
and Mike Karels of Berkeley.  My company, Advanced Computing
Envrionments is sponsoringn it, so I have some prejudice.
next week is probably too son for any bureaucracy to move,
but it is really your best bet for getting tons of good info in
a hurry.

Dan 

415-941-3399
PS.  Send me your US Snail addres so we can keep you informed of future
events.
-------

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 16:07:28 GMT
From:      sundc!hadron!rlgvax!dennis@seismo.css.gov  (Dennis.Bednar)
To:        tcp-ip@sri-nic.arpa
Subject:   Novell and TCP-IP interoperability
[The message below is posted for another CCI employee.
 Please send replies to me, and I will forward to him.
 Thanks.  dennis]



         MICOM
         TCP Gateway for Novell Netware
         
         I am looking for a site that has installed the MICOM TCP Gateway 
         for Novell Netware connected specifically to a UNIX system.  They 
         use their NP600G board in the file server.  The board allows PC's 
         connected to the Novell file server to log on a UNIX system.  For 
         my purposes it doesn't matter what topology they are using ( token 
         ring, starlan etc. ) but it does need to be connected to ethernet.  
         I understand the gateway works great but I need to reference a 
         site.  If anyone knows of a site that is using this board please 
         let me know.
         
         
                                  Thanks in advance for any help.
                                       BILL BURCH
-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 17:02:00 GMT
From:      Corrigan@DDN3.ARPA
To:        comp.protocols.tcp-ip
Subject:   FTP Checkpoint

The FTP implementation on the Honeywell mainframe done for the World-Wide
Military Command and Control System (WWMCCS) implements and uses checkpoint/
restart.  It also lets you begin a transfer, leave, and check back later on 
status.  They used to move huge files in the mid/late 70's and restart was
essential for operational, not cost, reasons, because the system didn't stay
up long enough to complete very many transfers.  The checkpoints were based o
time, not number of records transfered, because the variability in throughput
was high, and minimizing the amount of lost time was the important issue.  I
think 5 minutes between checkpoints was the default.
  All this continues to work as we speak -- of course the protocol it is 
running over is NCP......

Mike

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 18:39:58 GMT
From:      jeremy@swatsun.uucp (Jeremy Brest)
To:        comp.protocols.tcp-ip,comp.os.vms,comp.protocols.misc,comp.protocols.appletalk
Subject:   Any experiences w/ DECnet in a multi-vendor environment?

I'm interested in any experiences that anyone has had with trying to
use DECnet as the central protocol in a multi-vendor network
environment.  How well (i.e., transparently) do the following work?

	1) remote login to local sites?
	
	2) remote login to wide area TCP-IP networks?

	3) file transfer between local sites?

	4) file transfer (anonymous FTP) over wide area TCP-IP
	networks?

	5) local mail?

	6) mail through wide area networks, including uucp, bitnet,
	wide area TCP-IP networks, and CSNet?

Other concerns are how Macintoshes and MS-DOS machines fit into the
picture.  I know that with TCP-IP, software has been developed to
provide login and file transfer, as well as sever implementations of
mail systems.  What about with DECnet?  

I'm also interested in how might a heterogenious network work out,
that is, have a few machines that spoke both TCP-IP and DECnet, but
most machines speaking one or the other.

Thanks,

Jeremy Brest
Swarthmore College

uucp:      ...seismo!bpa!swatsun!jeremy
CSnet:     jeremy@swatsun.swarthmore.edu
Internet:  jeremy%swatsun.swarthmore.edu@relay.cs.net

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 20:55:19 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Many things on ethernet together???

XNS and TCP/IP will coexist on an Ethernet.  They use different Ethernet
Type numbers.

I have the TCP/IP version of flight simulator when you're ready.

-Ron

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 21:23:55 GMT
From:      wiltzius@lll-lcc.aRpA (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   Raw Sockets


I'm being a bit lazy here:  I want to use an IP raw socket to
implement a non-Internet transport protocol on IP (please, this
is an exercise and not my idea).  The particular UNIX system
is Sun's 3.2.

Can only "super-user" use the IP raw socket?  I suspect this is
a silly question, but can there only be one process on the system
using the IP raw socket?  For those of you that did this (as it
was intended) to prototype and debug transport code, what was the
difference in performance between the raw socket implementation and
the kernel implementation.

Any comments as an aside would be welcome - perhaps more appropriately
as E-mail.  Thank you.
--------------------------------------------------------------------
Dave Wiltzius (wiltzius@lll-lcc.llnl.gov)

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 May 88 23:10:20 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Another problem with usage charges

The discussion of refunding aborted FTPs reminds me of a common trick among
the Cornell RJE terminal operations staff back during my undergrad hacking
days.

The system (IBM OS/360, batch oriented) charged for each line actually
printed. However, since line printers jam from time to time, the RJE
operator could command the system to restart a print job from the
beginning, canceling the charges for the copy already printed. But it
became common practice among those operators whose funny-money accounts
were running low to add several pages of unneeded garbage to their job
output. When the useful stuff had all been printed, they would restart
the job and then kill it, thus costing them NOTHING for the output they
did print.

Clearly any FTP refund scheme would invite exactly the same sort of
abuse.

On the other hand, I would like to repeat a quote I saw on the net almost
10 years ago. I wish I could remember who said it. It seems relevant to
the subject at hand:

"There may be no such thing as a free lunch, but sometimes it costs more
to collect money than to give away food".

Phil

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      4 May 88 04:44:16 GMT
From:      wales@CS.UCLA.EDU
To:        sci.research,comp.protocols.tcp-ip
Subject:   Research on protocol optimization for slow networks?

I am looking for any leads to recent research on the question of how
to improve the performance of a communications protocol to make it more
acceptable for use over a "slow" network link.

By "slow", I am thinking (roughly speaking) of 9600 bits/sec or slower
for interactive work.  If the application involves transfer of large
amounts of data, then some people might consider faster links (e.g.,
56K bits/sec) to be "slow".

I'm open to the possibility of improving protocol performance at any or
all levels.  I haven't tried to narrow myself down very much yet.

I'm aware, for instance, of the work of various high-speed modem manu-
facturers in implementing data compression and/or certain protocols in
their modems (e.g., Telebit's UUCP packet protocol implementation).
But I haven't had much luck in finding other material.

Any pointers to current or recent research in this area would be grate-
fully appreciated.

-- Rich Wales // UCLA CS Dept // wales@CS.UCLA.EDU // +1 (213) 825-5683
   3531 Boelter Hall // Los Angeles, California 90024-1596 // USA
   ...!(ucbvax,rutgers)!ucla-cs!wales       ...!uunet!cs.ucla.edu!wales
   "Mr. LaForge, when I left this ship it was in one piece!"

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 May 88 05:40:04 GMT
From:      RMRichardson.PA@XEROX.COM (Rich)
To:        comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

In article <51442@sun.uucp> limes@sun.com (Greg Limes) writes:

> In article <218@turbo.RAY.COM> Robin@turbo.RAY.COM (Robin Alston) writes:
 
> >Can XNS and TCP-IP share the same coax cable with no possible problems?
 
> ... It is even possible (gag) to run both TCP/IP and XNS through the same 
> physical interface, but the bottom layer does need to know where to send 
> each packet type. ... 

My workstation can talk PUP, XNS and TCP/IP simultaneously, i.e., three 
connections at once, all on the same wire.  I make no claims about speed, 
etc., just that it can be done, so you should be able to do the same.  

> >Can we have our own domain (we really have no interest at this time in
> >talking to our vaxes), while decnet has its own on the same cable?

This should be ok; the fun part comes when you do want to talk to each 
other.  Then you need an XNS package on the vaxes, or TCP-IP on your other 
machines.  

Rich

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 May 88 17:42:45 PDT
From:      croft@csli.stanford.edu (Bill Croft)
To:        tcp-ip@sri-nic.ARPA
Cc:        croft@csli.stanford.edu, karwowska@dg-rtp.dg.com
Subject:   re: Public Domain Software for BOOTP
> Date: 28 Apr 88 19:11:28 GMT
> From: rti!xyzzy!karwowska@mcnc.org  (Joanna Karwowska)
> Subject: Public Domain Software for Bootp
> 
> I would like to get an access to the public domain software
> for remote bootstrap protocol - bootp (RFC951).
> Can anybody help?
> 
> 		Joanna Karwowska
> 		karwowska@dg-rtp.dg.com
> 			   Data General, Research Triangle Park, NC
> 			<the known world>!mcnc!rti-sel!rtp46!karwowska

You can anonymous FTP the files 'bootp.client.shar' and
'bootp.server.shar' from the pub directory on safe.stanford.edu.  The
client code autoconfigures to find and boot from a couple of different
ether interfaces (3COM/Interlan).  The server runs under 4.X BSD UNIX.
A number of vendors are now supporting this boot mechanism.
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 May 88 14:39:31 GMT
From:      dheeraj@chakra.cs.umd.EDU
To:        comp.protocols.tcp-ip
Subject:   LSRR option in IP


I have been trying to use LSRR option of IP to route a packet through
various machines on the campus. Most machines just drop the packet.
I went into the ip_input code. It seems that ip_forward(ip, ifp)
drops the packet if 
	1. ipforwarding is off OR
	2. in_interfaces is <= 1

That means that hosts with only one interface cannot have packets
loose source routed through them. I don't understand why this should
be the case. If some Gateway is trying to route the packet through
this machine, then it make sense to let the Gateway know that it is
inefficient to route the packet this way but if a user is forcing the
packet through this machine then I don't see why should the packet be
dropped.

Actually, if the machine has more than one interfaces and the routing
alogrithm decides to forward the packet through the same interface as
it came on then the packet is not dropped. (Isn't it similar to having
one interface and forwarding the packet through the same one.)

Thanks,
dheeraj sanghi

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      5 May 88 00:42:45 GMT
From:      croft@CSLI.STANFORD.EDU (Bill Croft)
To:        comp.protocols.tcp-ip
Subject:   re: Public Domain Software for BOOTP

You can anonymous FTP the files 'bootp.client.shar' and
'bootp.server.shar' from the pub directory on safe.stanford.edu.  The
client code autoconfigures to find and boot from a couple of different
ether interfaces (3COM/Interlan).  The server runs under 4.X BSD UNIX.
A number of vendors are now supporting this boot mechanism.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      05/05/88 18:03:11
From:      Keith R. Hacke <M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Wollongong's TCP/IP
We are planning to purchase Wollongong's TCP/IP implementation for a MicroVAX
running VMS. I am particularly interested in its use for Domain Name Serving
between our Ethernet and the DDN (we have a Milnet connection). VMS is used on
our VAXs, UNIX on the Suns and Silicon Graphics.

What do you think of Wollongong's TCP/IP?

Is anyone using it for Domain Name Serving?  With a VAX running VMS?

Other ideas (I know about using a Sun for the Domain Server)?

Thanks
Keith R. Hacke
McDonnell Douglas
314-895-5343

PS  Thanks to those who gave info on D. Comer's TCP/IP book.  Our company
library is getting it.

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      5 May 88 13:27:31 GMT
From:      per@erix.UUCP (Per Hedeland)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Subnetting

Excuse me if the question below is trivial, but I really haven't seen much
discussion on subnetting, and neither RFC reading nor local asking-around
has gotten me very far...

This is the scenario: The basic structure of our LAN is a backbone segment,
to which a number of Sun server/client groups are connected. Each client group
has it's own Ether segment, with the server acting as gateway to the backbone.
Typically there are 5-10 clients in each group. There are currently some 20
such groups, but predictions are for hundreds in the not too distant future,
i.e. considering other connected equipment, far more than 256 addresses are
required for the backbone.

Due to us not being connected to the Internet, and inadequate planning of the
growth of the LAN, network numbering is a mess, which we would like to clean up
as soon as possible, and this prompts my question: It seems to be a terrible
waste of adress space to use a separate class C number for each of the client
groups, so we figured that subnetting would be appropriate, but how do we use
it to an advantage?

Specifically, given the abovementioned structure, there's a conflict between:

a) It appears that the intended use of subnetting assumes that all the "subs"
   of a "whole" net are interconnected, i.e. the backbone and the client
   segments in our case should be "subs" of the same "whole" - in particular,
   "automatic" routing by means of routed (which we desire) will not work
   otherwise, as far as I can understand.

and:

b) "Subs" of a given "whole" must be of equal size.

We do believe that the arguments for the current structure (such as handling
the load from diskless clients, avoiding extra cabling given the physical
location of servers and clients, allowing use of the backbone for e.g. DECnet
traffic) are valid, and it seems rather silly having to modify it to
accommodate the IP adressing scheme. But of course, neither the structure nor
the requirement for "automatic" routing are carved in stone, i.e. any and all
suggestions are welcome (preferrably via e-mail, and I will summarize to the
net if requested).

Thanks In Advance
--Per Hedeland

Internet: per@erix.ericsson.se
Non-MX:   per%erix.ericsson.se@uunet.uu.net
UUCP:     {mcvax,munnari,uunet}!enea!erix!per

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      5 May 88 13:29:41 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Bootp information

This is a request for information on the Bootp protocol. As I understand it,
this protocol allows a dumb device to be loaded from from a server device.

I am particularly interested to know if the protocol works using IP routers, 
subnets, fragmentation, etc. Also an approximation of the PROM space required 
to contain enough of this code to boot a device from power-up (i.e. one that 
doesn't know its own IP address)

Please send a pointer to the apropriate information to me directly. I will 
summarize to the net if there is enough interest.


Thanks in Advance
Bill VerSteeg

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 May 88 18:30:32 EDT
From:      Lyle Evans <EVANSL%VTVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Federation of American Research Networks (FARnet)
Sergio Heker <heker@jvnca.csc.org>  writes
> ...
>As a point of information, there is a task force whithin the Federation
>of American Research Networks (FARnet), working on this issue right now.

Could somebody give me some more information about the Federation of
American Research Networks FARnet ?

Lyle Evans (Bitnet: Evansl @ VTVM1 )
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      5 May 88 14:44:43 GMT
From:      ms6b+@ANDREW.CMU.EDU (Marvin Sirbu)
To:        comp.protocols.tcp-ip
Subject:   Whither Chargeback

The issues being discussed here regarding chargeback are faced regularly by
every corporation which has a private telecommunications network.  Consider the
following:

1.  What to do when different networks have different prices?
This is eminently true of today's telecommunications providers.  MCI, AT&T, and
Sprint all have different price schedules.  You can buy leased lines with flat
rates for service up to a bandwidth limit, WATS lines which are distance
insensitive but usage priced (after a minimum), and regular Direct Distance
Dialed (DDD) service which is priced by both time and distance.  Corporations
buy Private Branch Exchanges (PBXs) with Least Cost Routing (LCR) software
which decides on a call-by-call basis which network to use.  Calls go by
preference over leased lines since you've paid for them anyway.  If the leased
line is busy, there are several alternatives:  a) you get a busy signal and the
client places the call again, perhaps specifying an alternate carrier; b) the
call automatically overflows onto the next highest cost facility.  As to
chargeback in this environment, again there are several approaches.  You can
calculate the average cost per minute  over the various networks (leased lines,
WATS, etc.) for all calls from A to B and use that as the basis for chargeback.
 This puts the burden on the telecom manager to optimize the LCR and the
facilities to minimize total costs.  Or, particularly with option a) above, the
user pays the cost for the facility used; if he replaces the call on the DDD
network rather than waiting for the tie line to become free, he pays a higher
price for the call.  Time of day pricing leads users to defer traffic such as
mail to off peak hours.  This reduces the peak traffic and the corresponding
network capacity required.  There are lots of variations in between.

2.  Connection charges versus usage charges.
Both are clearly required.  Much of the network cost is in access, so
connection charges should probably recover a large chunk of the total cost.
But usage charges are also important:  how else do you justify investing in
that FTP implementation that uses the restart facility?  Usage charges create
incentives to write better software (or to go out and buy better software) that
will cut the usage cost.  In the same way, time  usage charges on DDD networks
lead customers to justify buying higher speed modems or data compression boxes.
 Right now, there is only the small incentive of minimizing processor
interrupts to get people to write network code that does sensible thinks about
packet acknowledgements.

3.  Money for capacity expansion.
In the U.S. the carriers have always financed capacity expansion out of profits
or borrowing.  In Europe, for example France before 1970, capacity expansion
had to be funded out of legislative appropriations; all profits were returned
to the treasury.  Anyone who ever tried to use a phone in France before 1970
knows how the French underfunded capacity expansion under this regime.
Corporations without chargeback to the internal users have the same problem
justifying appropriations from corporate budget directors.

4.  Volume discounts.
Volume discounts can make usage charges fair to both large users and smaller
ones.  After all, a T1 link costs less than 24 56 kbps links; large users
enable the network to buy more cost effective transmission links.  We have
volume discounts for electric power and for telecommunication users in the
commercial world.

4.  Cross subsidies.
There should be subsidies for various "deserving" users, like lifeline
telephone rates.  They should be explicitly targeted, not general for everyone.

Most of the issues being discussed have been faced and the consequences of
alternative policies understood by corporate telecom managers.  Some research
into what has already been done in other settings would be very useful.

Marvin Sirbu

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 May 88 23:03:31 PDT
From:      satz@clash.cisco.com
To:        tcp-ip@sri-nic.arpa
Subject:   DDN X.25 Standard diagnostic codes
Would someone be so kind as to forward me a copy of the latest DDN specific
diagnostic codes? The codes I have are from the latest DDN specification
circa 1983 and it seems newer codes are being returned in CLEAR REQUEST
packets. Thanks!
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      5 May 88 18:21:05 GMT
From:      paulf@Shasta.STANFORD.EDU (Paul A. Flaherty)
To:        comp.protocols.tcp-ip
Subject:   att.com domain wierdness


I've noticed that the att.com MX entry keeps on drifting between att.arpa
and rutgers.edu; can anyone give an explaination?

-- 
-=Paul Flaherty, N9FZX	     | One Internet to rule them all,    -- Tome
Computer Systems Laboratory  | One Internet to find them;            of 
Stanford University          | One Internet to bring them all,    Internet
->paulf@shasta.Stanford.EDU  | And in the Ether bind them.         Hacking

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      5 May 88 22:30:32 GMT
From:      EVANSL@VTVM1.BITNET (Lyle Evans)
To:        comp.protocols.tcp-ip
Subject:   Federation of American Research Networks (FARnet)

Sergio Heker <heker@jvnca.csc.org>  writes
> ...
>As a point of information, there is a task force whithin the Federation
>of American Research Networks (FARnet), working on this issue right now.

Could somebody give me some more information about the Federation of
American Research Networks FARnet ?

Lyle Evans (Bitnet: Evansl @ VTVM1 )

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 01:03:11 GMT
From:      M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke)
To:        comp.protocols.tcp-ip
Subject:   Wollongong's TCP/IP

We are planning to purchase Wollongong's TCP/IP implementation for a MicroVAX
running VMS. I am particularly interested in its use for Domain Name Serving
between our Ethernet and the DDN (we have a Milnet connection). VMS is used on
our VAXs, UNIX on the Suns and Silicon Graphics.

What do you think of Wollongong's TCP/IP?

Is anyone using it for Domain Name Serving?  With a VAX running VMS?

Other ideas (I know about using a Sun for the Domain Server)?

Thanks
Keith R. Hacke
McDonnell Douglas
314-895-5343

PS  Thanks to those who gave info on D. Comer's TCP/IP book.  Our company
library is getting it.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 01:45:51 GMT
From:      zemon@felix.UUCP (Art Zemon)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Many things on ethernet together???


Other people have given you the theoretical whys and
wherefores about doing this.  I thought I would chip in some
practical experience in case you are the type who wants
"real proof".  (I'm not trying to be derogatory here, just
helpful.)

We run one Ethernet cable with the following protocols on
it:

    TCP/IP
    XNS
    DECnet
    DEC LAT
    DEC MOP

Everything runs just fine.  Don't worry about it.
--
	-- Art Zemon
	   By Computer:	    ...!hplabs!felix!zemon
	   By Air:	    Archer N33565
	   By Golly:	    moderator of comp.unix.ultrix

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 May 1988 09:15:33 LCL
From:      John M Wobus <JMWOBUS@SUVM.ACS.SYR.EDU>
To:        TCP-IP Discussion Group <TCP-IP@SRI-NIC.ARPA>
Subject:   Discussion group on campus-sized networks.
This is a reminder that there is an electronic-mail "list" or "discussion
group" dedicated to campus-sized networks.  I created it largely because I
saw messages on the TCP-IP list that were really more about campus-sized
networks than about TCP-IP and thought it would be nice to have a place
where we wouldn't feel guilty discussing the stuff.  You are welcome to
join this list (which typically has about half the volume of TCP-IP).
See the "blurb" below.

John Wobus
Syracuse University

=-------------------
BIG-LAN@SUVM.ACS.SYR.EDU                 (Internet)
BIG-LAN@SUVM                             (Bitnet)

   This list is for the discussion of issues in designing and operating
   Campus-Size Local Area Networks, especially complex ones utilizing
   multiple technologies and supporting multiple protocols.  Topics
   include repeaters, bridges, routers and gateways; how to incorporate
   smaller Personal-Computer type LANs into the campus-wide LAN; how to
   unify the mail systems, etc.  This is an ideal list in which to debate
   the relative merits of bridges vs routers.

   All requests to be added to or deleted from this list, problems,
   questions, etc., should be sent to BIG-REQ@SUVM.ACS.SYR.EDU (Internet)
   or BIG-REQ@SUVM (Bitnet).  Those familiar with revised LISTSERV can
   subscribe with LISTSERV@SUVM.ACS.SYR.EDU (Internet) or LISTSERV@SUVM
   (Bitnet).

   Archives are available through revised LISTSERV.

   Coordinator: John Wobus <JMWOBUS@SUVM.ACS.SYR.EDU>
                           <JMWOBUS@SUVM>
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 06:03:31 GMT
From:      satz@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   DDN X.25 Standard diagnostic codes

Would someone be so kind as to forward me a copy of the latest DDN specific
diagnostic codes? The codes I have are from the latest DDN specification
circa 1983 and it seems newer codes are being returned in CLEAR REQUEST
packets. Thanks!

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 14:36:41 GMT
From:      JMWOBUS@SUVM.ACS.SYR.EDU (John M Wobus)
To:        comp.protocols.tcp-ip
Subject:   Discussion group on campus-sized networks.


This is a reminder that there is an electronic-mail "list" or "discussion
group" dedicated to campus-sized networks.  I created it largely because I
saw messages on the TCP-IP list that were really more about campus-sized
networks than about TCP-IP and thought it would be nice to have a place
where we wouldn't feel guilty discussing the stuff.  You are welcome to
join this list (which typically has about half the volume of TCP-IP).
See the "blurb" below.

John Wobus
Syracuse University

=-------------------
BIG-LAN@SUVM.ACS.SYR.EDU                 (Internet)
BIG-LAN@SUVM                             (Bitnet)

   This list is for the discussion of issues in designing and operating
   Campus-Size Local Area Networks, especially complex ones utilizing
   multiple technologies and supporting multiple protocols.  Topics
   include repeaters, bridges, routers and gateways; how to incorporate
   smaller Personal-Computer type LANs into the campus-wide LAN; how to
   unify the mail systems, etc.  This is an ideal list in which to debate
   the relative merits of bridges vs routers.

   All requests to be added to or deleted from this list, problems,
   questions, etc., should be sent to BIG-REQ@SUVM.ACS.SYR.EDU (Internet)
   or BIG-REQ@SUVM (Bitnet).  Those familiar with revised LISTSERV can
   subscribe with LISTSERV@SUVM.ACS.SYR.EDU (Internet) or LISTSERV@SUVM
   (Bitnet).

   Archives are available through revised LISTSERV.

   Coordinator: John Wobus <JMWOBUS@SUVM.ACS.SYR.EDU>
                           <JMWOBUS@SUVM>

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 15:33:53 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Subnetting

In article <1607@erix.UUCP> per@erix.ericsson.se (Per Hedeland) writes:
>
>Typically there are 5-10 clients in each group. There are currently some 20
>such groups, but predictions are for hundreds in the not too distant future,
>i.e. considering other connected equipment, far more than 256 addresses are
>required for the backbone.
 
>                                                   It seems to be a terrible
>waste of adress space to use a separate class C number for each of the client
>groups, so we figured that subnetting would be appropriate,

It does to me, too.  So, why not just use class B addresses?  Based on the
criteria you dictate, that would seem to be adequate for now and the future.

-bc
-- 
Bill Crews                                   Tandem Computers
bc@halley.UUCP                               Austin, Texas
..!rutgers!im4u!halley!bc                    (512) 244-8350

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 19:39:34 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Campus Network Query

Greg,  There is excellent brand new book on thart subject.  It is called
"Campus Networking Strategies", Caroline Arms, Editor.  It is "sponsored" by EDUCOM, published by Digital Press, ISBN 1-55558-009-2, Order No. EY-6736E-DP.

It is a collection of description sof the campus networks and how they came to 
be.  All written by knowledgable people.  The campuses included are:
Wesleyan, Dartmouth, CMU, Rensselaer, MIT, Stanford, Cornell,
Michigan, Minnesota and Penn State.

Dan
-------

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 23:49:17 GMT
From:      egisin@watmath.waterloo.edu (Eric Gisin)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Many things on ethernet together???

One thing no-one has mentioned yet is the case where the ethernet type
is a valid 802.3 packet length.  I think Xerox PUP falls
in to this catagory (what's PUP anyway?).

What do 802.3 compatible systems do with such packets?
VMS 4.4, for example, supports 802.3 LLC headers.

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 May 88 23:53:11 GMT
From:      chris@MIMSY.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   A new record?

PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes
64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms
64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms

So where *was* that packet for four minutes and 13 seconds?
(Maybe it was routed via the University of Mars :-) )

Chris

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      7 May 88 04:09:30 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Campus Network Query

Dan,

That sounds like a fantastically useful book. Do you have information on
publisher or ISBN?

Dave

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      7 May 88 11:50:06 GMT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: A new record?

Chris: not a record, unfortunately.  Dave Mills, at least, has one
that returned after 16 minutes and something -- I'll bet there are
even better ones.
						Scott

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      7 May 88 12:24:09 GMT
From:      milazzo@RICE.EDU (Paul Milazzo)
To:        comp.protocols.tcp-ip
Subject:   Re: A new record?

Chris:

I once ran ping for hours on a newly-installed proNet-10, with
similarly frightening results.  My host, a lightly-loaded VAX-11/750,
was pinging itself because it was the only host on the ring.  Amidst
thousands of 20 msec round-trip times, one ping returned---out of
sequence---after 11.5 seconds!

Where could it have hidden for that long?  I assume it was parked in an
mbuf somewhere; a three-million kilometer detour seems unlikely...

				Paul G. Milazzo <milazzo@rice.EDU>
				Dept. of Computer Science
				Rice University, Houston, TX

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      7 May 88 13:17:57 GMT
From:      steven@lakesys.UUCP (Steven Goodman)
To:        comp.protocols.tcp-ip
Subject:   3.1 & Excelan


	Recently installed the Excellan TCP/IP software and 205T board
	in an AT&T 8386 box, running AT&T's UNIX System V Release 3.1.
	The Excellan software is 8014-01.

	The machines seem to be able to "talk" ok with the exception of
	some failures with "rcp", "ftp", and "rsh" (remsh).  Now Excellan
	does not presently support 3.1 and I am looking for someone whom 		perhaps has this package presently running under 3.1.  
	
	Actually with the exception of the above problems, the system 	
	appears to perform fairly well although I have not yet done any
	programing with this package, any exchange of information regarding
	this would be appreciated.  The other machines are running the "WIN"
	TCP/IP on AT&T 3B15's and UNIX 2.1.2.

	Some of the failures are in having the WIN software talk to the 
	Excellan, and could possibly be the resault of the new stuff 	
	in 3.1 ( ie; /etc/shadow ) although I have not yet spent alot of
	time examining this possibility.  It's unfortunate that I have only
	one Excellan package running to examine if this is a problem 
	resaulting in the 2.1.2 and 3.1 or WIN to Excellan.   

	Might also mention that I would gladly assist anyone attempting
	this port as well to get you at least as far as we have. 

	
-- 
Steven M. Goodman
Lake Systems -  Milwaukee, Wisconsin
{ihnp4,uwvax}!uwmcsd1!lakesys!steven
{rutgers,uunet}!marque!/

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      7 May 88 15:11:58 GMT
From:      Doug_Nelson@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

In message <1607@erix.UUCP>, Per Hedeland writes:
 
>  a) It appears that the intended use of subnetting assumes that all the "subs"
>     of a "whole" net are interconnected, i.e. the backbone and the client
>     segments in our case should be "subs" of the same "whole" - in particular,
>     "automatic" routing by means of routed (which we desire) will not work
>     otherwise, as far as I can understand.
 
Yes, that has to be true - you can only advertise your full network,
not your subnets, to the Internet at large.
 
>  b) "Subs" of a given "whole" must be of equal size.
 
This is a mistaken assumption.  There is nothing that prevents you
from using subnets of different sizes on a given net, except for
software that isn't up to speed on subnetting (notably SunOS 3.x).
For example, our campus-wide network is a class B sized subnet of a
class A network.  The Merit network itself is a class A/2 subnet, and
Univ of Michigan has parceled out a number of class C-sized subnets.
I plan to pass out class C-sized subnets of our network (or possibly
smaller) to several other campus Ethernets, as soon as we get SunOS
4.0 installed.
 
Doug Nelson                   den@serv1.cl.msu.edu
Michigan State University     08071den@msu.bitnet
Computer Laboratory

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      8 May 88 02:03:27 GMT
From:      earle@mahendo.Jpl.Nasa.Gov (Greg Earle)
To:        comp.protocols.tcp-ip
Subject:   The ultimate solution to the packet chargeback problem

In article <[A.ISI.EDU]29-Apr-88.18:15:38.CERF> cerf@a.ISI.EDU writes:
>The accounting issue comes up for two reasons: the MILNET operation folks
>need to allocate costs among the users of MILNET and the general growth
>of the Internet infrastructure can't be supported solely on government
>subsidy in today's climate.

I say add an extra MX missile or two to the military's budget request for each
year, but instead funnel the money to AT&T et al. to pay for all the
ARPANET & MILNET network links.  That way we don't need chargeback, the
government can subsidize it, and I'll feel just an epsilon better about where
my tax dollars went.  Without politicizing the argument, there is so much
waste of government money in the military-industrial complex that I don't
see how anyone in the government could complain about having to subsidize
these networks, which are a sterling example of non-wasted monies buying
such virtuousness  :-)  I mean, how many months of a 56 Kb line could be
paid for with the price of an Air Force plane toilet seat?

There.  That was easy, now wasn't it?

[ BTW: :-) ]
-- 
	Greg Earle		earle@mahendo.JPL.NASA.GOV
	Indep. Sun consultant	earle%mahendo@jpl-elroy.ARPA	[aka:]
	(Gainfully Unemployed)	earle%mahendo@elroy.JPL.NASA.GOV
	Lake View Terrace, CA	...!{cit-vax,ames}!elroy!jplgodo!mahendo!earle

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      8 May 88 04:24:48 GMT
From:      wilson@laic.UUCP (Robin Wilson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???


We have a very large network here at Lockheed.  We have Ungermann/Bass
terminal servers using XNS, and Vaxen using DECnet, SUNs using NFS and
TCP, Symbolics using CHAOS (TCP derivative), and assundry "special"
cases using there own brand of protocols.  Our primary concern, in
having them all use the same cable (baseband Ethernet bridged together
with protocol independant VitaLink TransLAN Bridges), is coordinating
additions of new devices of the SAME protocol.  For example, I work at
the Research Lab in Palo Alto, and we are bridged over a VitaLink to the
main Lockheed facility in Sunnyvale; we are constantly having problems
when the Sunnyvale people connect stuff up to their network and forget
to tell us.  One time, our DECnet crapped out because we were set to
route to only 30 nodes.  The Sunnyvale facility had connected a very
extensive network to theirs using a VitaLink, the new network had about
40 DECnet nodes, and when they added them to our DECnet, our router
began to swap between the thirty most recently seen nodes, and then
trashed.  The long and the long (no short story here) of it is that if
you connect alot of different protocols to your network, be sure you
keep tight reigns on the addition of new devices, some of them may have
effects you never dreamed of on your other nodes out there.

R.D. WILSON  "Keep your grubby paws off of my views!"

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      8 May 88 16:02:14 GMT
From:      wd@dg2kk.rmi.de (Walter Doerr)
To:        comp.protocols.tcp-ip
Subject:   Info on TCP/IP book wanted

Can anyone please tell me the price of Doug Comer's book about TCP/IP.
I'd like to know because ordering US book here in Germany can be quite
expensive.

Thanks.

Walter

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      8 May 88 16:44:23 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Chaosnet (Re: Many things on ethernet together???)

In article <233@laic.UUCP> wilson@laic.UUCP (Robin Wilson) writes:
>... Symbolics using CHAOS (TCP derivative)...

Point of information: the Chaos protocols are not TCP-derivative. They
were developed independently at the MIT AI Laboratory just before or
at about the same time as TCP was first being worked on. The Chaosnet
protocols were developed along with the Chaosnet hardware, which is
pretty much gone today.  They look a lot like TCP except that Chaos
addresses are smaller, the reliable stream protocol is sequences
blocks of data rather than bytes, and the "IP" and "TCP"-like parts of
it are smooshed together, Chaos has 'contact names' rather than well
known ports...well, the Chaos protocols bear some resemblance, anyway.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      8 May 88 19:12:51 GMT
From:      joe@tekbspa.UUCP (Joe Angelo)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Subnetting

in article <358@halley.UUCP>, bc@halley.UUCP (Bill Crews) says:
> Xref: tekbspa comp.dcom.lans:150 comp.protocols.tcp-ip:495
> 
> 
> It does to me, too.  So, why not just use class B addresses?  Based on the
> criteria you dictate, that would seem to be adequate for now and the future.
> 

Now, the classes of IP addresses is simple enough to understand --

But what about subnetting? When does one want to *really* use
two IP network address on the same cable? And what performance
advantages does this give you? Were does the netmask come it at?
Is subnetting just a nice admistrativia thing? Or does your local
enet board not receive the packets, period? Or is it the high
level software that ignores the packet? Does anything really ignore
anything? 

-- 
"I'm trying             Joe Angelo -- Senior Systems Engineer/Systems Manager
 to think               at Teknekron Software Systems, Palo Alto 415-325-1025
 but nothing
 happens!"              uunet!tekbspa!joe -OR- tekbspa!joe@uunet.uu.net

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      8 May 88 21:00:45 GMT
From:      ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff)
To:        comp.protocols.tcp-ip
Subject:   Re: A new record?

In article <8805062353.AA23117@mimsy.umd.edu> chris@MIMSY.UMD.EDU (Chris Torek) writes:
>PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes
>64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms
>64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms
>
>So where *was* that packet for four minutes and 13 seconds?
>(Maybe it was routed via the University of Mars :-) )
>
>Chris

Well, in 253.239 seconds light can travel 75,971,700 klicks.
Mars is (ruff-ly) around 120,000,000 klicks away right now, so it didn't
get routed through the Protion gateway at U of Mars.  My guess
is that some VAX at a circular partical accellerator is going
flakey and routed this ICMP into the partical beam path...round and
round your data goes...

--ritchey ruff	ruffwork@cs.orst.edu -or- ...!hp-pcd!orstcs!ruffwork

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 07:27:22 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

> >  b) "Subs" of a given "whole" must be of equal size.
>  
> This is a mistaken assumption.  There is nothing that prevents you
> from using subnets of different sizes on a given net, except for
> software that isn't up to speed on subnetting (notably SunOS 3.x).

Unfortunately, there -are- problems with dividing a network into
variable-sized subnets -- not just incomplete software implementations
but real engineering problems.  They relate to cases where hosts or
gateways need to know the size of a subnet they're not attached to:
e.g. when interpreting an ICMP network redirect, synthesizing a remote
broadcast address, or routing to a remote subnet.

You may be able to live with the effects of misinterpretations if things
are kept simple enough (so long as nothing sends you a network redirect :->).

The subnetting RFCs, e.g. 917, 936, 950 discuss some possible conventions
for determining subnet sizes, including equal sizes on a given network (easy)
and self-encoding subnet sizes analogous to the class A/B/C sizing for ordinary
networks.  I suppose it would also be possible to distribute a table of
subnet sizes to every host and gateway on a network.  But in general,
you -do- have to be able to know the sizes of sibling subnets, and the
equal-size case seems to be the closest one to a standard.

	Stuart Levy

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 12:11:05 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted

In article <477@dg2kk.rmi.de> wd@dg2kk.UUCP writes:
> Can anyone please tell me the price of Doug Comer's book about TCP/IP.
> I'd like to know because ordering US book here in Germany can be quite
> expensive.

I got my copy at Reiter's bookstore in Wash. DC for $36.00 - I assume
this is the list price.  I haven't read the whole thing yet, but it
appears to be an excellent overview of the subject...

-- 
George Robbins - now working for,	uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 18:33:00 EST
From:      <wontrop@bluto.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   TCP/IP for WANG devices?
I am doing a report for a client within the Federal
Government.  Does anyone know of an implementation
of TCP/IP for either the WANG Alliance Minicomputer
or the WANG Wise Box?

The configuration includes DOS terminals connected
to the Alliance Minicomputer forming a star, and
some Wise Boxes - All WANG equipment.

I do not know the exact operating system
version, and I have tried the TCP/IP vendors
guide.  

Any help would be appreciated.  Please send
responses directly to me...I will post if 
anyone else is interested in this.

			Thanks

			Ron Wontrop
			Contel Federal Systems
			WONTROP@BLUTO.SCC.COM


-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 15:34:15 GMT
From:      dls@mace.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting


	Differing subnet sizes are not really a problem on all systems--
the "only if your software isn't up to snuff" comment applies.
	4.3BSD includes enhancements to ICMP to ask for the interface's
netmask ("ICMP_MASKREQ"). I don't know of any user-level program that uses
this (yet).
	Also, I don't think it's been clear that the "variable size" subnets
are by individual bits, not just bytes. You can split a class B net number
into 17 bits of network and 15 bits of host, if that's what you really want
to do. Some software only supports A subnetted to B and B subnetted to C
(ie, by bytes), though. Void where prohibited. Your mileage may vary.
	Of course, if you have sources, you can fix it.
-- 
					+-DLS  (dls@s.cc.purdue.edu)

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 16:11:40 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting


	
	> >  b) "Subs" of a given "whole" must be of equal size.
	>  
	> This is a mistaken assumption.  There is nothing that prevents you
	> from using subnets of different sizes on a given net, except for
	> software that isn't up to speed on subnetting (notably SunOS 3.x).
	
	Unfortunately, there -are- problems with dividing a network into
	variable-sized subnets -- not just incomplete software implementations
	but real engineering problems.  They relate to cases where hosts or
	gateways need to know the size of a subnet they're not attached to:
	e.g. when interpreting an ICMP network redirect, synthesizing a remote
	broadcast address, or routing to a remote subnet.
	
Stuart,

Let's consider the three examples you cite.  

Network Redirect:  It is recognized that network redirects are a problem
in a subnetted environment, and therefore the Gateway Specification
RFC-1009 says that gateways should only be sending host redirects.
If you have a gateway within your subnetted environment that is sending
network redirects, it should be brought up to spec.

Synthesizing a remote broadcast -- presumably you mean a directed
broadcast. Yes, this is a real engineering problem, although it is an
application-level problem, not an IP level problem.  If you have an
application that is sending directed broadcasts into another subnet of
the same network, that application needs some configuration information
-- obviously, it needs the remote subnet number.  You might as well
configure it with the complete 32-bit Internet directed broadcast
address.  Synthesizing IP addresses should be avoided whenever possible.

Routing to a remote subnet -- This is entirely a gateway problem.
The solution, as RFC-1009 suggests, is simply to include the
subnet masks with the network numbers in the routing updates among
the subnet gateways.  I wonder why no one has extended RIP in this
obvious way yet.  As you say, it is merely a matter of a little
engineering.   
   
After all this, I would challenge your statement that "in general,
you -do- have to be able to know the sizes of sibling subnets"
(at least, if "you" is a host, not a gateway).

Bob Braden

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 16:15:45 GMT
From:      bzs@bu-cs.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted



>Can anyone please tell me the price of Doug Comer's book about TCP/IP.
>I'd like to know because ordering US book here in Germany can be quite
>expensive.

I don't see any list price on it, I bought it at Stacey's in Palo
Alto, CA for $36.00. Beyond that you should probably call Prentice-Hall.

	-Barry Shein, Boston University

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 16:32:08 GMT
From:      Doug_Nelson@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

As a couple of you have pointed out, routing is the problem with
multiple subnets of different sizes.  We manage routing within our
subnet very trivially - we don't really do routing, since we have
only a single gateway to the outside world.  I encourage our Sun
owners to add a default route pointing to their own system, which
adds a few ARPs to our local network, but finds the gateway just fine.
 
What really is needed is a subnet routing protocol which passes netmasks
along with the network numbers.  Is anyone working on this yet?  Can
anyone tell me if 4.3bsd includes the netmask in each routing table
entry?  We need this to make such a protocol usable.
 
Doug Nelson

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 17:21:12 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: The ultimate solution to the packet chargeback problem

> ...  Without politicizing the argument, there is so much
> waste of government money in the military-industrial complex that I don't
> see how anyone in the government could complain about having to subsidize
> these networks...

You don't understand how bureaucrats work. When faced with a budget
crunch, they do NOT respond by trimming the most wasteful expenditures
first. Rather, they immediately zero in on the most visible, efficient,
essential and popular programs, hoping that the resulting public
backlash will pressure the legislators into restoring their original
budget.

This is a standard ploy at all levels of government.

Phil

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 17:45:19 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Honeywell and DG

Good morning all!
	I am going to be running Honeywell and Data General systems on a
LAN soon and have been told by a customer that they have TCP/IP implement-
ations running on them. Does anyone have any comments, suggestions, war
stories or anything else that relates to these implementations? I have never
been one for reinventing the wheel and would be very grateful for any
input that could make this a bit easier.
			Thanks in advance,
					  Chris VandenBerg
					  ACC
					  chris@acc-sb-unix.arpa

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 18:37:55 GMT
From:      ed@mtxinu.UUCP (Ed Gould)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Subnetting

>Now, the classes of IP addresses is simple enough to understand --
>
>But what about subnetting? When does one want to *really* use
>two IP network address on the same cable? And what performance
>advantages does this give you? Were does the netmask come it at?

The purpose of subnetting is not to run multiple IP addresses
on the same cable, but to make a local collection of networks
appear as if it were one network from the outside.  To do this,
one takes a standard IP adress (ususally a Class B address, but
this isn't required) and uses some of the bits that are normally
the "host number" part of the address as if they were part of
the "network number."  The netmask determines the division between
host part and network part that is used locally.

For example, consider the following /etc/hosts excerpt, which lists
several Class B addresses.  Keep in mind a netmask of 0xFFFFFF00
(the normal Class B netmask is 0xFFFF0000).

	129.1.1.1	main-sys
	129.1.2.1	main-sys-gw
	129.1.2.2	second-sys
	129.1.2.3	third-sys

One topology this could represent is

  net to outside	 internal net
    (129.1.1)		  (129.1.2)
	________   _________________________________
	       |   |              |                |
	       |   |              |                |
	    -----------     -------------    --------------
	    |         |     |           |    |            |
	    | main-sys|     | second-sys|    | third-sys  |
	    |         |     |           |    |            |
	    -----------     -------------    --------------

In this case, there are two physical networks:  one connecting the
three machines locally, and one connecting the main system to the
outside world.  To the outside world, the three machines look as if
they are connected together on a single Class B network.  Internally,
though, they look as if they were on two separate Class C networks with
a gateway.

-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
{ucbvax,uunet}!mtxinu!ed    +1 415 644 0146

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 18:40:45 GMT
From:      PAYNE@CDCCENTR.BITNET (JAMES M. PAYNE  (612) 482-2575  CDC  ARH207)
To:        comp.protocols.tcp-ip
Subject:   RIP

YES WE ARE CONSIDERING RIP.
JIM

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 20:26:09 GMT
From:      espo@bpa.BELL-ATL.COM (Bob Esposito)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted


	The price is $46.00 for Doug Comer's TCP/IP book.


-- 
Bob Esposito, Bell of Pennsylvania     uucp: {rutgers|cbmvax|bellcore}!bpa!espo
A Bell Atlantic Company              domain: espo@bpa.bell-atl.com
Philadelphia, PA.                     phone: +1 215 466 6831
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 22:16:34 GMT
From:      mckay@ea.ecn.purdue.edu (Dwight D Mckay)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???


While we're on the topic:

Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and
AppleTalk (ethertalk?)?

--Dwight Mckay, ECN Workstation Software Support
[arpanet: mckay@ee.ecn.purdue.edu, usenet: ...ihnp4!pur-ee!mckay]
[Compu-serve: 75776,1521, office: EE 348B, phone: (317) 494-3561]

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      9 May 88 23:33:00 GMT
From:      wontrop@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for WANG devices?

I am doing a report for a client within the Federal
Government.  Does anyone know of an implementation
of TCP/IP for either the WANG Alliance Minicomputer
or the WANG Wise Box?

The configuration includes DOS terminals connected
to the Alliance Minicomputer forming a star, and
some Wise Boxes - All WANG equipment.

I do not know the exact operating system
version, and I have tried the TCP/IP vendors
guide.  

Any help would be appreciated.  Please send
responses directly to me...I will post if 
anyone else is interested in this.

			Thanks

			Ron Wontrop
			Contel Federal Systems
			WONTROP@BLUTO.SCC.COM

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 01:23:39 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

OK.  If we have permission to squash systems sending subnet redirects
it'll make the situation easier.  (At the University of Minnesota
we've had real operational problems with this in the past.)

And when we do have routing protocols that carry explicit subnet masks
I'll happily shut up.

It'll still seem useful, though, OK, maybe not essential for hosts to
be able to find the subnet structure of a net.  For sending directed
broadcasts, suppose you want to say "broadcast on the net where host X lives"
where X is known by name.  It might be desirable to use the normal mechanism
for finding X's address rather than hard-wiring an IP address into an
application.  In that case, since the domain name system doesn't (and shouldn't)
record network structure, how could you find the right broadcast address?
Admittedly this may stretch the point a bit but not too far, I think.

Likewise, if a host and several gateways are on some (sub)net, the host might
want to set up its routing tables for a "good" choice of gateway to other
subnets.  Granting that routing should work if the host picks -some- gateway
and depends on that to forward and/or redirect traffic as needed, it could
still make good use of the information if it could get it.

Again, routing protocols designed for variable-sized subnets would let this
happen naturally.


	Stuart

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 01:50:38 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting


	
	It'll still seem useful, though, OK, maybe not essential for hosts to
	be able to find the subnet structure of a net.  For sending directed
	broadcasts, suppose you want to say "broadcast on the net where host X lives"
	where X is known by name.  It might be desirable to use the normal mechanism
	for finding X's address rather than hard-wiring an IP address into an
	application.  In that case, since the domain name system doesn't (and shouldn't)
	record network structure, how could you find the right broadcast address?
	Admittedly this may stretch the point a bit but not too far, I think.

Stuart,
	
Directed broadcast is generally a poor idea (the right solution is the IP
multicasting).  No architectural decision should be taken on the grounds
that it makes makes directed broadcasting easier.
	
	Likewise, if a host and several gateways are on some (sub)net, the host might
	want to set up its routing tables for a "good" choice of gateway to other
	subnets.  Granting that routing should work if the host picks -some- gateway
	and depends on that to forward and/or redirect traffic as needed, it could
	still make good use of the information if it could get it.

I disagree.  The Internet standard approach for a host: pick any
gateway and let it redirect you... is simple and effective. You REALLY
DON'T want hosts to know about routing, even subnet routing!!
	
Bob Braden
	

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 02:08:29 GMT
From:      lear@athos.rutgers.edu (eliot lear)
To:        comp.protocols.tcp-ip, paulf@Shasta.STANFORD.EDU
Subject:   Re: att.com domain wierdness


Thank you for your note.  The problem has been noted and corrective
action has been taken on this end.
-- 
Eliot Lear
[lear@rutgers.edu]

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 13:25:13 GMT
From:      almes@RICE.EDU (Guy Almes)
To:        comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

RD:
  The key point here is that ethernet is a ``local area network'' technology,
and that its designers *never* intended it to be a wide area network.  This is
not to say that long-distance bridging is never the right thing to do, but
only that you should not be surprised when it exhibits limits.
  This idea of `local' suggests, not only physically proximity, but also
adminstrative unity.  In your case, it wasn't the physical distance, but
the administrative distance that caused the problems.  If you stay with the
single pseudo-ethernet bridged approach, then you will need to have admini-
strative structures that treat it as a single ethernet.
	-- Guy

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 14:24:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???


    Date: 8 May 88 04:24:48 GMT
    From: pyramid!leadsv!laic!wilson@decwrl.dec.com  (Robin Wilson)

False information alert!

    ... Symbolics using CHAOS (TCP derivative) ...

Chaos is not a TCP derivative.  Chaos was in active service at MIT
around 1978 or so, which I think was before TCP became operational.
Chaos is more a derivation of (Xerox) PUP and Arpanet NCP, with a bunch
of things "fixed."  In some ways it is more powerful than TCP/IP, and in
some ways less.  It is certainly not a derivative of TCP, even though
Chaos's designers worked in the same building as some of the major
contributors to the TCP design.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 16:51:17 GMT
From:      tsf@arizona.edu (Ted Frohling @ CCIT-Telcommunications, University of Arizona)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted


The price for Douglas' book is $US 36.00.
-- 
Ted Frohling                               Internet: tsf@rvax.ccit.arizona.edu
Network Support                            BITNET:   tsf@arizrvax.BITNET 
CCIT - Telecommunications                  AT&T:     (602) 621-4834
University of Arizona, Tucson, AZ 85721

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 16:59:13 GMT
From:      mckee@fiona50a.ccs (george mckee)
To:        comp.protocols.tcp-ip
Subject:   controlling IP "type of service"

Thinking about network pricing policies and accepting for the moment
that relays don't grow on trees, I see on p.12 of RFC791 a description
of a "Type of Service" field in an IP packet header that requests
different levels of delay, throughput, and reliability, as well as
specifying priorities ranging from "routine" through "flash override"
and beyond.
	Do any of the popular implementations actually try to set this
field, and does it affect the delivered performance of the network?
(My Unix man page for ip(4P) says "other options are ignored".)

	- George McKee
	  NU Computer Science

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 17:23:56 GMT
From:      jsloan@wright.EDU (John Sloan)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Plenum-Rated Ethernet Transceivers

I've seen references on the net to plenum-rated ethernet transceivers
but have never read any specific citations. Plenum-rated transceivers
could be used in the plenum, the environmental air space above drop
ceilings (and other places). Plenum-rated transceiver and coax cable is
common.

I note that the standard DEC transceiver says on its label very
specifically that it is NOT plenum rated, as do the BICC and 3COM
transceivers we use. The Cabletron transceiver literature says
"conforms to UL 910 and NEC 725-2(b) requirements for installation in
air-handling spaces". A quick phone call to our rep had him reading this
verbatum over the phone, which wasn't much help. Other phone calls have
yielded similar results.

A call to our University electrician, who is supposed to know at least
the codes, was not of much use.

So here I am wasting everyone's bandwidth. Does anyone have specific
recommendations, including vendor name and part number? If anyone else
is interested, I'll investigate it from there and summerize results.

Thanks!

-- 
John Sloan, The SPOTS Group    Wright State University Research Building
CSNET: jsloan@SPOTS.Wright.Edu  3171 Research Blvd., Kettering, OH 45420
UUCP: ...!cbosgd!wright!jsloan          +1-513-259-1384  +1-513-873-2491
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 17:29:04 GMT
From:      chuck@excelan.UUCP (Chuck Kollars)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP 
(Dwight D Mckay) writes:
>...Is it possible to have Novell NetWare on the same wire with TCP/IP, 
XNS and AppleTalk (ethertalk?)?

Yes, all protocols can run on the same Ethernet wire at the
same time.  Novell's network OS can run over many different 
media, one of which is Ethernet.  

If you're using Ethernet with NetWare, consider attaching 
*all* the NetWare Servers and *all* the Workstations to one 
Ethernet cable.  Multiple NetWare Servers on a single cable 
works fine.  And the Workstations will have direct access 
not only to the NetWare Servers, but also to all the 
non-NetWare nodes if and when they need it.  
-- 
Chuck Kollars,   Excelan, Inc.   (chuck@excelan.UUCP)
mabell: (408) 434-7434	Internet: mtxinu!excelan!chuck@ucbvax.Berkeley.COM
telex: 176610		uucp: ...!{mtxinu,leadsv,cae780}!excelan!chuck
fax: (408) 434-2310	post: Excelan, 2180 Fortune Drive, San Jose CA, 95131

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 May 88 00:24 CST
From:      Derek Andrew <ANDREW%SASK.BITNET@CORNELLC.CCS.CORNELL.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: Re: Many things on ethernet together???
We run many different protocols over the same Ethernet network.  We have
encountered one problem which is currently under study.

We had these two 3COM labs for our students.  Each lab has a file server.  When
both labs were added to the campus network, the servers would both compete for
control over the workstations.  That is, machines in one lab would try to log
into the server in the other lab.

The moral of the story is that it is not multiple protocols that will kill you,
but rather networking companies like 3COM with limited vision as to the
environments in which their products will be used.

Note that we run XNS in the 3COM labs, not TCP/IP.

Derek Andrew, Manager of Computer, Networking and Technical Services
              University of Saskatchewan

andrew@sask on bitnet
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      10 May 88 23:21:11 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

>	The Internet standard approach for a host: pick any
>gateway and let it redirect you... is simple and effective. ....
but works abysmally given the typical host software that allows you
either to (1) set a static default route to the world, or (2) run
passive RIP or something like it.  If I choose option 1 and the default
gateway crashes, it won't be around to send ICMP redirects telling me
to use the backup gateway.  Phrased differently, the "Internet
standard" does not adequately address the issue of how a host should
pick the first gateway to try.

>You REALLY DON'T want hosts to know about routing.
At issue here is a critical point:  how smart is it desirable for hosts
to be?  Braden argues that they should be very dumb.  I would argue
that they can be dumb if they don't really need connectivity off their
network, but should be a little bit smarter if possible.  If you
concede that, then the next step is to decide whether it is better for
a host to have:  (1) a static list (n>1) of gateways to try; (2) some
as yet undefined dynamic discovery mechanism for a host on a network to
find the list of gateways without getting routing data; (3) hosts that
listen to routing traffic and hence could potentially use the data to
avoid that first bad choice of a gateway.

My personal bias:  Passive RIP works just fine in the XNS world as a HOST
protocol as well as as a gateway protocol.  It works adequately in the
IP world for typical CANs and moderately complex LANs.  I see no real
alternative available at present.

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 00:33:12 GMT
From:      bob@cloud9.UUCP (Bob Toxen)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Many things on ethernet together???


You can run just about any protocl on the same ethernet cable.
This is because anyone wanting to devise a new protocol is supposed
to obtain a protocol number from Xerox.  This protocol number is
encoded in the sent packet.  Receivers are expected to recognize only
the protocols they are prepared to deal with.  This is why this works.
-- 

Bob Toxen	{ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob
Stratus Computer, Marlboro, MA
Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank?

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 00:51:06 GMT
From:      RMRichardson.PA@Xerox.COM (Rich)
To:        comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

From: clyde!watmath!egisin@bellcore.com (Eric Gisin)
> One thing no-one has mentioned yet is the case where the ethernet type is
> a valid 802.3 packet length.  I think Xerox PUP falls in to this catagory
> (what's PUP anyway?).

PUP -- PARC Universal Packet
PARC -- Palo Alto Research Center (Xerox)

It means you can't talk PUP to hosts that act that way.  One way around 
this is to change the PUP type numbers to outside the valid length range.  
This means all the PUP speakers on the net must all do this or you will 
have split the net into two types of PUP speakers who can talk to only 
their own type.  The other is to hack the other guy (e.g., VMS) to figure 
out what is coming in.  

Rich

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 03:28:20 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Question about LLC


I hate to admit this, but I don't know diddly about the new 802 LLC frame
format.  Is there an RFC or some document on sri-nic that describes this
format?  If not, what texts contains such a description?

The reason I ask is because devices on our net use the old dst/src/type
format and now some of the newer devices are using the dst/src/len/llc
and I can't make heads or tails of what these new devices are "saying".

What is the `correct' way to refer to dst/src/type (IEEE 802.?) ?
The `correct' way to refer to dst/src/len/llc (IEEE 802.3)?  

Thanks in advance.

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of Electrical & Computer Engineering 
 @__|_______@  |       Parallel Processing Research Group (PPRG)
 |  |       |  |       UNM/LANL Hypercube Project
 |  |  hc   |  |    Albuquerque, New Mexico 87131
 |  @.......|..@    
 | /        | /     e-mail:      
 @/_________@/        cyrus@hc.dspo.gov

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 03:51:40 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

It looks as though 4.3BSD subnetting code doesn't store a net mask per route.
There's a net mask per -interface-, but it doesn't seem to be used the
way you'd hope.  There's effectively just one subnet mask per net for
routing purposes (I think it uses the mask set by the first interface on
the net) -- that is, 4.3BSD silently assumes equal-sized subnets on a
given net.  If I say

	ifconfig ex0  128.101.1.2    netmask 255.255.255.0
	ifconfig ex1  128.101.27.27  netmask 255.255.240.0

the interface route for ex1 has a destination address of "128.101.16.0"
(reasonable) BUT the route is only used when sending to 128.101.16.anything.
Sending to 128.101.17.anything, ..., 128.101.31.anything does not increment
the interface route's usage count.

4.3's multiple subnet masks are meaningful for interfaces on different nets
but not for variable-sized subnets on a single net.  It'll be interesting to
see whether SUN 4.0 works the same way.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 04:19:17 GMT
From:      greg@vertical.oz (Greg Bond)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) writes:
>Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and
>AppleTalk (ethertalk?)?

Certainly is. We have one thin enet cable here running SUNs (TCP/IP)
and NetWare 2.0a concurrently. In fact, I have a PC that has a 3com
enet card talking PC-NFS (TCP) and a Gateway G-net card talking Netware
(on a separate cable!) at the same time. So if I had 2 enet cards I guess
I could do both at once on the same cable from the same PC.
-- 
Gregory Bond,  Vertical Software, Melbourne, Australia
Internet: greg@vertical.oz.au	(or greg%vertical.oz.au@uunet.uu.net)
UUCP: {uunet,pyramid,mnetor,ukc,ucb-vision}!munnari!vertical.oz!greg
ACSnet: greg@vertical.oz

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 04:28:59 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Honeywell and DG

In article <8805091745.AA24461@ACC-SB-UNIX.ARPA> chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) writes:
>Good morning all!
>	I am going to be running Honeywell and Data General systems on a
>LAN soon and have been told by a customer that they have TCP/IP implement-
>ations running on them.

I don't know about DG, but I know that Honeywell Bull has several
completely unrelated operating systems, running on almost as many
different hardware architectures: GCOS-8, Multics, GCOS-6, and HVS1 to
name a few (there's another I know of, but can't think of the name).
Which one are you talking about?

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 04:29:15 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, chris@mimsy.umd.edu
Subject:   Re: A new record?


In article <8805062353.AA23117@mimsy.umd.edu> chris@MIMSY.UMD.EDU (Chris Torek) writes:
>PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes
>64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms
>64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms
>
>So where *was* that packet for four minutes and 13 seconds?

Presumably in various gateway queues.  However you might also check
your ping to make sure it handles timing correctly when lots of
packets are being dropped.  One could imagine a bug that would
cause it to report a time for the wrong one.  This has happened
to TCP implementations, as I'm sure you know.

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 May 88 09:46:05 EDT
From:      "Drew M. Powles" <dpowles@ccd.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        dpowles@ccd.bbn.com
Subject:   Who's got the time?
Can someone please tell me which protocol is the most widely accepted
for synchronizing Network Time?  What work is being done in this area?
What do most vendors implement?  Is it RFC 958?  Is there a later
version? 

Thanks in advance for any and all information. 

Drew Powles 
BBN Communications 
dpowles@bbn.com


-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 06:24:00 GMT
From:      ANDREW@SASK.BITNET (Derek Andrew)
To:        comp.protocols.tcp-ip
Subject:   RE: Re: Many things on ethernet together???

We run many different protocols over the same Ethernet network.  We have
encountered one problem which is currently under study.

We had these two 3COM labs for our students.  Each lab has a file server.  When
both labs were added to the campus network, the servers would both compete for
control over the workstations.  That is, machines in one lab would try to log
into the server in the other lab.

The moral of the story is that it is not multiple protocols that will kill you,
but rather networking companies like 3COM with limited vision as to the
environments in which their products will be used.

Note that we run XNS in the 3COM labs, not TCP/IP.

Derek Andrew, Manager of Computer, Networking and Technical Services
              University of Saskatchewan

andrew@sask on bitnet

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 09:52:18 GMT
From:      whna@cgcha.uucp (Heinz Naef)
To:        comp.protocols.tcp-ip,comp.protocols.ibm,comp.sources.wanted,eunet.general
Subject:   TCP/IP-to-SNA File Transfer Gateway

We are planning to implement a TCP/IP-to-SNA file transfer gateway to be used
as a central service to provide file transfer capabilities between our TCP/IP
network and some IBM MVS mainframes hanging off an SNA network.

Our evaluation resulted in a concept based on an application level gateway,
where the application is the most commonly used file transfer mechanism at
each side of the gateway:

- At the TCP/IP side, it is, of course, the File Transfer Protocol (FTP).

- At the SNA side, we are thinking of an implementation based on the
  Enhanced Connectivity Facility (ECF) File Copy function.
  As a first step, we are planning to implement the requester (client)
  function of the IBM 3270 PC File Transfer Program.

Please remember the following requirements:
- The service only needs to ASYMMETRIC, where the IBM SNA side plays the
  passive role.
- The service *has to* be INTERACTIVE because of security systems at the
  IBM hosts.
- Development of software for the IBM hosts *must be* avoided. Only the gateway
  -- which could be an IBM -- can incorporate new software.

With the proposed solutions, development of server entities for the IBM hosts
can be avoided, since there are IBM program products available for both
major operating systems, MVS and VM. Furthermore, possible requirements for
a batch file transfer capability can be met by adding the Batch File Transfer
Program (BFTP) - upon its availability - to the TCP/IP side of the gateway.

Did anyone attempt or even complete an implementation of such a gateway?
Please reply by mail, I will summarize your comments within a month or so.

Thanks in advance, and best regards,

Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.62, P.O.Box, CH-4002 Basel 
  uucp: whna@cgch.uucp - bitnet: whna%cgch.uucp@cernvax.bitnet 
                         phone:  (+41) 61 37 26 75 
                         fax:    (+41) 61 36 43 54 (Attn: H.Naef, R-1032.5.62)

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 12:29:07 GMT
From:      mo@maximo.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Comer's book

Price correction: $36.00

At least, that's what I paid for it at Jim Joyce's
UNIX Bookstore.  For another $6 you get it UPS Blue.

	-Mike

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 13:46:05 GMT
From:      dpowles@CCD.BBN.COM ("Drew M. Powles")
To:        comp.protocols.tcp-ip
Subject:   Who's got the time?

Can someone please tell me which protocol is the most widely accepted
for synchronizing Network Time?  What work is being done in this area?
What do most vendors implement?  Is it RFC 958?  Is there a later
version? 

Thanks in advance for any and all information. 

Drew Powles 
BBN Communications 
dpowles@bbn.com

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 14:26:42 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted

Typos and comments concerning Doug Comer's TCP/IP book can be sent to:

tcp-typos@cs.purdue.edu  or {ucbvax,decvax,ihnp4}!purdue!tcp-typos

This is not a mail list, so please do not ask to join; it serves as a
collection point for funnelling comments back to the author.

Sorry, no points given for noting the mistake on the front cover.

Thomas Narten

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 17:08:22 GMT
From:      stewarta@sco.COM (Stewart I. Alpert)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) writes:
>
>While we're on the topic:
>
>Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and
>AppleTalk (ethertalk?)?
>
 Yes

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 17:41:22 GMT
From:      bruce@ssc-vax.UUCP (Bruce Stock)
To:        comp.protocols.tcp-ip
Subject:   802 (.2).3 TCP/IP


Does anyone have any wisdom to share regarding the ability of TCP/IP versions
based on Ethernet 2 frame formats to communicate with 802 (.2).3 based
versions ( on the same network)?  

I just got a flyer for the Wollongong WIN/H3000 software (FTP, Telnet, SMTP)
for the HP 3000 series of computers.  This package uses the underlying 
802 (.2).3 frame formats of HP's TCP/IP implementation for its lower layers.
Most ( all?) other TCP implementations seem to use the Ethernet 2 frame 
formats and would probably not communicate with this package.  
Any experience to relate?

It would seem that HP's TCP/IP implementation is grossly out of step with 
prevailing practice in the TCP arena.  Are there any reasons to choose it,
based on either short term or long term considerations?


			Bruce E. Stock
			Boeing Aerospace
			uw-beaver!ssc-vax!bruce

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 21:17:02 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Password transmission and encryption query

Recently, some people here have begun to grumble about the insecurities of
having user passwords transmitted in the clear during TELNET sessions, FTP
transfers, etc. I was wondering what solutions other places have devised to
deal with this problem. I'd appreciate any information that TCP-IP readers
have and any pointers to more information.

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

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 22:28:15 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   another TCP/IP book

There has been much recent discussion of Comer's new INTERNETWORKING
WITH TCP/IP on this list.  My librarian tells me that there is another
similar book, AN INTRODUCTION TO TCP/IP, by John Davidson.  It was
published by Springer-Verlag this year.  It provides "an overview of
TCP/IP.  Contents: introduction, data link layer, network layer,
transport layer, session through application layers."  Has anyone seen
the latter book?  How does it compare with the Comer book?

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 06:25:51 PDT (Thursday)
From:      "Thomas_D._Herbst.HENR801c"@Xerox.COM
To:        tcp-ip@sri-nic.Arpa
Cc:        jqj@hogg.cc.uoregon.EDU
Subject:   Re:another TCP/IP book
>Date: Wed, 11 May 88 15:28:15 PDT
>From: jqj@hogg.cc.uoregon.edu
>Subject: another TCP/IP book
>
>There has been much recent discussion of Comer's new INTERNETWORKING
>WITH TCP/IP on this list.  My librarian tells me that there is another
>similar book, AN INTRODUCTION TO TCP/IP, by John Davidson.  It was
>published by Springer-Verlag this year.  It provides "an overview of
>TCP/IP.  Contents: introduction, data link layer, network layer,
>transport layer, session through application layers."  Has anyone seen
>the latter book?  How does it compare with the Comer book?

I was rather disappointed with the Davidson book.  While it does provide an
introduction, it doesn't cover very much material in the depth that I require.
It is a useful book for people that don't have to implement anything, say a
manager trying to answer the question "What is this TCP/IP stuff, anyway?".

I am anxiously awaiting my special ordered copy of Comer's book.

tom
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 23:49:40 GMT
From:      brian@cbw1.UUCP (Brian Cuthie)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted

In article <477@dg2kk.rmi.de> wd@dg2kk.UUCP writes:
>Can anyone please tell me the price of Doug Comer's book about TCP/IP.
>I'd like to know because ordering US book here in Germany can be quite
>expensive.

It's $36.00.

It is a very good book.  Ties alot of things together that would never
be apparent from the RFCs.  The nice thing is that he didn't try to
replace the RFC's, but rather gives an overview of the internet and
the protocols while refering to the RFCs for details.

-brian


-- 
Brian D. Cuthie                                 uunet!umbc3!cbw1!brian
Columbia, MD                                    brian@umbc3.umd.edu

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      11 May 88 23:52:32 GMT
From:      brian@cbw1.UUCP (Brian Cuthie)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted

In article <588@bpa.BELL-ATL.COM> espo@bpa.UUCP (Bob Esposito) writes:
>
>	The price is $46.00 for Doug Comer's TCP/IP book.
                     ^^^^^^

No wonder my phone service is so expensive.  Do you bell guys get such 
a deal on everything ?? :-)

-brian



-- 
Brian D. Cuthie                                 uunet!umbc3!cbw1!brian
Columbia, MD                                    brian@umbc3.umd.edu

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 01:01:00 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Dumb vs. smart host routing

In article <8805102321.AA26819@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes:
>>You REALLY DON'T want hosts to know about routing.
>At issue here is a critical point:  how smart is it desirable for hosts
>to be?  Braden argues that they should be very dumb.  I would argue
>that they can be dumb if they don't really need connectivity off their
>network, but should be a little bit smarter if possible.

As the network grows the part which will give out is the routing
substrate. The Internet has already had this happen a few times. We
went from GGP to EGP, then EGP broke and it had to support multiple
packet updates, and now we're in the process of scrapping EGP for the
next step. Each of these steps was good enough for networks of a
certain size and broke as the network grew.

If we can keep the hosts as stupid as possible with regard to the
routing algorithms and bottle the complexity up in the routers then
we're in a better position to deal with the next time the Internet
hits a level where the existing routing protocols break. Whatever the
next solution is, it may not hold for 10,000 networks. Or 100,000
networks. With one or two hundred hosts per network.

[I've been working with TCP/IP long enough that when I started, we
called routers 'gateways', so know that I'm using them as synonyms in
this message.]

I'd rather treat the network as a black box from the host's point of
view. For a host with a single network interface, I think the best
way for it to route is to have a list of default gateways which it
cycles through, caching a route with a 'connection'. If TCP notices
problems with lots of retransmissions, it could call IP and request
that it reroute the connection (IP flushes the route and uses a
different default gateway). Since the gateways know the TRUTH they can
send ICMP redirects when they believe there is a better route.

If some new protocols were cooked up to allow hosts to query routers
for some useful information WITHOUT the hosts understanding how the
routers worked, that would be okay as far as I'm concerned.

Multihomed hosts are a more substantial problem, and right now they
probably do have to at least listen to routing protocols in order to
figure out the best routes to use.

This way, the next time the routing substrate breaks because the
Internetwork has grown too much, only the routing substrate needs to
be changed. Just fixing this will be a bad enough problem without
having to change all the host software in the world. We'll have a lot
more flexibility to change the routing substrate then.

-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 01:44:12 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about LLC

Check out RFC1042.

Drew

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 03:29:36 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about LLC (802.2 packet formats)

RFC1042 documents the official method for encapsulating IP (with a 'SNAP'
header) in 802.2 packets.  For complete information on 802.2 LLC, as the
IEE envisioned it, I think you need to get the 802.2 standard itself from
the IEEE.

I always refer to them as "802.3" and "Bluebook" (from the DEC-Intel-Xerox
"Blue Book" which was the original Ethernet standard).  Some other people
refer to them as "Ethernet" and "802.3", but I feel that is confusing to
the neophyte.  (It is kind of rough on someone who has just read his first
"LANs are Great" article when you say "Ethernet and 802.3 really are
different, trust me...".)

jbvb

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 04:21:14 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: controlling IP "type of service"

> 	Do any of the popular implementations actually try to set this
> field, [TOS] and does it affect the delivered performance of the network?

Mine (the KA9Q package) does. My IP interprets the "delay" and
"reliability" bits in the AX.25 (amateur packet radio) subnet driver as
follows:

1. If the "low delay" bit is set, send the datagram in an unnumbered
information (UI) frame. There is no link level flow control or
acknowledgment on these frames.

2. Else if the reliability flag is set, send the datagram as one (or more)
regular information (I) frames, opening a new link connection if
necessary. I frames are acknowledged and flow controlled at the link
layer according to LAPB (the protocol on which AX.25 is based). The "or
more" part refers to the possible use of subnet fragmentation and
reassembly to keep the physical frames small without imposing an
unreasonably small MTU on the IP layer.

3. Else use the interface's default encapsulation mode.

Although the driver does look at these bits, this is just a hook for
future use. At present my applications do not give the user the ability
to control these bits in generated datagrams.  The default mode is
presently used for all datagrams.

Phil

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 12:47:17 GMT
From:      andy prokop@ntmtka.UUCP (andy prokop)
To:        comp.protocols.tcp-ip
Subject:   Public domain telnet/ftp

I have been asked by an acquaintance from another company (without access to
Usenet) to find out if there are public domain versions of Telnet and FTP
for Unix.  Actually, they have a Unix look-alike (no ATT code), but that
shouldn't matter.  He wants source code, but I believe object might also do if
he knew exactly what the program expected from the OS and runtime environment.
Replies can either be posted or emailed directly to me.  Thanks.

| Andrew Prokop       ems!ntmtka!andy |
| Northern Telecom, Inc.              |
| 9705 Data Park   (612) 932-8758     |
| Minnetonka, MN 55343                |

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 13:25:43 GMT
From:      hubcap@hubcap.UUCP (Mike Marshall)
To:        comp.protocols.tcp-ip
Subject:   Doug Comer's TCP/IP book...

I can't comment on Doug Comer's TCP/IP book, but I can suggest another
book that I know to be very good... "Handbook of Computer Communications
Standards, VOL 3" which deals with the DOD protocol standards. The book's
authors lend it credibility, for example, Paul Mockapetris also wrote
several RFC's including "Domain Names - Concept and Facilities". 

After having to turn to the book for reference several times, I have decided
to buy the other two books in the series...

   [1] OSI model & related standards
   [2] Local Network standards

Has anyone read both Comer's book and HCCS VOL-3? Any comments?

-Mike Marshall      hubcap@hubcap.clemson.edu       ...!hubcap!hubcap

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 14:45:24 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Yes, although some question may remain on your "popular" qualifier. The
present NSFNET Backbone gateways (Fuzzballs) do interpret the TOS and
Precedence fields and order the queues accordingly. So far as I know,
no other implementation, including the new NSFNET Backbone gateways (IBM),
interpret those fields, with the possible exception of the SATNET/WIDEBAND
gateways (LSI-11/Butterfly), which at one time mapped the TOS field
to specialized services available in these packet-satellite nets.

Dave

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 15:36:52 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

One problem I see is that ICMP Redirect is largely useless.  It's only
useful for the first gateway along the way to tell the originating host
to use a different gateway; it can't be used to tell an intermediate
gateway what the proper next hop is.  That is, assume we have a large
LAN behind a single gateway G to the Internet.  If a host H on that LAN wants
to talk to host H' on another LAN behind another gateway G', all
H can do is send the packets to G.  G must know that G' is the proper
next hop; if it chooses to use G'' instead, G'' cannot send an ICMP
Redirect.  Or rather, it can, but the Redirect will go to H, which can't
do anything but send to G no matter what it receives.  G'' doesn't know
that the packet came from G, and hence can't advise G of the proper route.
(To be sure, RFC1009 says that gateways within an autonomous system
can use Redirects among themselves, but that's not a standardized
use for the Internet.)

The conclusion of all this is that local gateways must be extremely
smart.  The current scheme, with EGP, works well enough in the current
environment, where there's one central net (ARPANET+MILNET); it would
fail miserably if there were a large number of interconnected backbone
nets.

I'm not certain what to do about the problem.  If Record Route were used
more, or Loose Source route, a host could handle such a redirect more
intelligently.  (Of course, under the current spec it wouldn't be sent.)
Perhaps we need a new option, ``Last Hop''; it would tell each gateway
the immediate predecessor gateway to be advised of a routing correction.
Then we'd need some new sort of Redirect message, possibly one that includes
a loose source route, rather than just a simple gateway address.  The
combination of these might even allow a very smart gateway to straighten
out twisty paths, though I'm not sure that that's feasible.  And the
security implications of enhanced Redirects needs to be considered very
carefully.


			--Steve Bellovin
			ulysses!smb
			smb@ulysses.att.com

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 15:53:49 GMT
From:      jon@CS.UCL.AC.UK.UUCP
To:        comp.protocols.tcp-ip
Subject:   Survey of TCP/IP Management Tools


I am conducting a survey of tools available for TCP/IP
internetwork management that are in the public domain,
or distributable freely, if with notice or whatever.

I may include a list of some of the sorts of
non-public domain tools that exist for comparison (e.g. some BSD 
handy things like rdist etc).

I will collate answers and forward to this list when
a reasonable set is accumulated.

So far, the kind of tools I am thinking of fall loosely into
three categories:

A: Configuration management:
e.g. UCL have a (n)awk based account management tool, that generates
accounts, password files, mail aliases , nfs mount table parameters
and so on.

Programs for allocating addresses and names safely, would fall  into
this category. Programs for checking routing set ups for consistency
might also go here.

Domain name test suites might go here too.

Programs for gathering traffic matrices fall into this category - and
some network dimensioning tools might be handy (help answer
where do i cut my ethernet type questions).

B: Fault Detection:
e.g. We have a version of ping that is driven by knowledge of
the topology, (but does not use source route or record, unfortunately)
and can therefore track where a link is down in a path. This is
combined with a telnet level ping, to say what the state of
any host is at the end of a path...it has a termcap driven
graphic display...

C: Performance management:
e.g. tcpdump type programs that allow non-intrusive
sensible analysis of protocols as they operate.
e.g. traffic generators for UDP/TCP etc


Note that I am interested mainly in collecting small tools that
may be plugged together in a nice fashion rather than monolithic
be all and end all systems, and I am biased towards simple existing
network solutions - programs that depend on the more sophisticated
features in gateways or hosts are no use, since all heterogeneous 
networks are lowest common denominator by defn.

I would prefer not to restrict the list to Unix based tools, though
I know shareware tends to come from that domain more than others.

if answers could be of the form it would help:

A/B/C	name 	OS 	description 	Anon-FTP?	Restrictions

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 16:10:58 GMT
From:      postel@VENERA.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   re: Question about LLC

W. Tait Cyrus:

Try looking at RFC-1042 for some clues.

--jon.

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 16:24:48 GMT
From:      forrest@LBL.GOV
To:        comp.protocols.tcp-ip
Subject:   Davidson's book vs. Comer's book

I recently read both books, starting off as a complete novice. As I recall,
the introduction to Davidson's book states that the book used to be a
document that was distributed to marketing and sales people so that they'd
have some idea what all the buzz words mean (my interpretation). With this
as a goal the book is OK. But, I wanted a more in depth study of TCP/IP which
is why I turned to Comer's book. Comer's book is MUCH better although some
of the chapters (specifically those dealing with routing) didn't feel right.
This is probably my fault and I intend to reread the whole book a second time.

For the time being, Comer's book is the only entry in the race for the
perfect TCP/IP book. Anyone new to TCP/IP, or anyone who wants to fill in
holes in their knowledge would benefit greatly from reading it. I know I did.

By the way, on page 40, the second high order bit on a class C address is
shown incorrectly in Figure 4.1 (this was pointed out to me by someone else).
I've submitted this type to the tcp-typos account.

Jon Forrest
Lawrence Berkeley Lab.
FORREST@LBL.GOV

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 16:38:33 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Who's got the time?

Drew,

First, let me point out that I am far from an unbiased source. Probably
the most widely implemented time protocol is UDP/TIME, which is distributed
with vanilla Unix. The 4.3bsd Unix distributions include a time daemon
which manages time distribution within a LAN, but would not be suitable for
use over most multi-net Internet paths. The Network Time Protocol (NTP)
described in RFC-958, as amended, was specifically intended for time
distribution both within a LAN and as far as the Internet eye can see.
A 4.3bsd daemon for NTP is available from MIke Petry (petry@trantor.umd.edu).

There are varying opinions on the robustness and accuracy of various
time-synchronization mechanisms in the literature. The NTP design was
based on models used by digital common carriers and uses maximum-likelihood
estimation and nonlinear-filtering techniques. A survey of different
approaches to the problem, the factors the led to the NTP design choices
and a comprehensive bibliography on the subject can be found in the
~ftp/pub/ntp.doc file in the anonymous directory at louie.udel.edu. This
document has been printed as a departmental report and submitted as an
RFC.

In my opinion it does not make sense to porpose a new service without
extensive experimentation and evaluation of a prototype implementation.
NTP was born three years ago and has been in regular use since that time
with at least three radio-synchronized time servers (now with five).
As the result of this experience the original NTP design was thoroughly
overhauled and tested over the last six months. The resulting NTP design,
including algorithms necessary to improve accuracy and mitigate between
possibly broken or bogus clocks (falsetickers), is described in the cited
document. All five of the radio-synchronized NTP servers, as well as all
Fuzzball secondary servers (e.g. NSFNET Backbone gateways) and many Unix
secondary/retail servers now tick the new version. In most places where
such things can be measured, the service provides time acccurate to within
a few tens of milliseconds and has an incredible degree of redundancy.

Dave

P.S. Truechimers may wish to subscribe to the list ntp@trantor.umd.edu
for additional information.

DLM

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 16:56:52 GMT
From:      jqj@hogg.cc.uoregon.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing

John,

  I sympathize, and agree that yours is a defendable position.  One
problem with it is that it doesn't work if the local network is
extremely dynamic, with lots of routers coming and going.  An "ad
absurdum" extension to your argument is that a host shouldn't have to
have ARP; it should be able to make do with some static tables -- of
course, that would be ridiculous since the list of hosts on the local
network is much too dynamic to make such a table reasonable (though
note that some implementations, e.g. SunOS 3.x diskless bootstrap,
required just such a table).

  Similarly, I claim that we will need some sort of discovery mechanism
if the list of gateways on a local network is expected to be large and
dynamic.  We have such a discovery mechanism in place today; passive
RIP.  I'm not recommending that we improve it, or that hosts use it for
anything except finding the first gateway.

  Note that if in fact most host implementations already supported a 
list of default gateways then I'd be willing to live with that as an
alternative.  Unfortunately, they don't; most implementations give you
exactly ONE default, which is not enough when that gateway crashes and
stops sending ICMP redirects.

>fixing this will be a bad enough problem without having to change all
>the host software in the world
I believe that a gateway can be taught to send out RIP packets saying
"I'm a default router" without sending out any other data.  If so, this
would provide my desired discovery mechanism with no changes to a
common flavor of host software (i.e. BSD derivatives).

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 May 88 16:53:49 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Survey of TCP/IP Management Tools

I am conducting a survey of tools available for TCP/IP
internetwork management that are in the public domain,
or distributable freely, if with notice or whatever.

I may include a list of some of the sorts of
non-public domain tools that exist for comparison (e.g. some BSD 
handy things like rdist etc).

I will collate answers and forward to this list when
a reasonable set is accumulated.

So far, the kind of tools I am thinking of fall loosely into
three categories:

A: Configuration management:
e.g. UCL have a (n)awk based account management tool, that generates
accounts, password files, mail aliases , nfs mount table parameters
and so on.

Programs for allocating addresses and names safely, would fall  into
this category. Programs for checking routing set ups for consistency
might also go here.

Domain name test suites might go here too.

Programs for gathering traffic matrices fall into this category - and
some network dimensioning tools might be handy (help answer
where do i cut my ethernet type questions).

B: Fault Detection:
e.g. We have a version of ping that is driven by knowledge of
the topology, (but does not use source route or record, unfortunately)
and can therefore track where a link is down in a path. This is
combined with a telnet level ping, to say what the state of
any host is at the end of a path...it has a termcap driven
graphic display...

C: Performance management:
e.g. tcpdump type programs that allow non-intrusive
sensible analysis of protocols as they operate.
e.g. traffic generators for UDP/TCP etc


Note that I am interested mainly in collecting small tools that
may be plugged together in a nice fashion rather than monolithic
be all and end all systems, and I am biased towards simple existing
network solutions - programs that depend on the more sophisticated
features in gateways or hosts are no use, since all heterogeneous 
networks are lowest common denominator by defn.

I would prefer not to restrict the list to Unix based tools, though
I know shareware tends to come from that domain more than others.

if answers could be of the form it would help:

A/B/C	name 	OS 	description 	Anon-FTP?	Restrictions
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 18:38:09 GMT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing

>One problem with it is that it doesn't work if the local network is
>extremely dynamic, with lots of routers coming and going.

I envision networks where links to other networks come and go, but not the
actual routers themselves. It's a strange idea to me. I don't see any
application for it off the top of my head.

>An "ad absurdum" extension to your argument is that a host shouldn't have to
>have ARP; 

No, I think there's a big difference between the two examples. I don't want
the hosts to have complete lists of all the routers on their network. Just
a list of a few - the default routers. Many systems nowadays have an idea
of one default router; I'd like to increase it to an arbitrary list of them
which is cycled through for reliability. If you have only one default router
then you lose big when it goes down. Since the routers all talk to one
another, they know the best routes and if the default router chosen for
a particular connection isn't the best, it will send an ICMP redirect and
the host should change its route.

It occurs to me that we're agreeing to some extent, but arguing over details.
I don't care too much how the host discovers what its default routers are.
Could be statically configured (though this isn't too good), BOOTP or
some new broadcast ICMP message.

I think that the details that we're disagreeing over are:

1. How many routers the host knows about. I want it to only have to know about
	a few. I don't really care how many, I'd like it to be more than one.
	At least nothing should depend on it knowing about them all.
	It doesn't bother me if the host does or doesn't know them all;
	ICMP will clean up the mess.

	I'm not sure that we're really disagreeing over this one...

2. How it discovers them. I'm very opposed to the host discovering routes
	by using routing protocols that the routers use internally. Having
	part of the routers' protocol be an interface to hosts which says
	"I'm a default router" or "This is a list of default routers for this
	subnet" is okay, as long as the host implementations don't sticky
	their fingers by prying open the routing protocols any more than that.

	If there's some way to do it without a broadcast protocol, or with
	one that minimizes the number of broadcasts, that would be a good
	thing.
				- john
-------

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 18:43:19 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Password transmission and encryption query

The kerberos authentication system can help solve this problem.  When
both hosts in a transaction are using kerberos, it is never necessary
to send passwords across the network.  For remote login, we have
already modified Berkeley Unix rlogin to use kerberos.  A kerberos
solution could be written for other operating systems as well.

The documents describing the protocol are available via anonymous FTP
from athena-dist.mit.edu (at 18.71.0.38).  The code is currently in
beta test (we've been using a version at MIT for over a year now), and
will be released at some point in the future.  If you cannot use FTP
or want more information, you may send a request to
info-kerberos@athena.mit.edu.
					-Mark Rosenstein

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 19:25:16 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: another TCP/IP book

There's no comparison; the Davidson book is a fairly cursory overview (though
probably still valuable to a novice), while Comer treats stuff in depth.
Davidson's introduction describes the book as essentially a set of lecture
notes; that's a fairly accurate description.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 20:12:34 GMT
From:      pete@BRILLIG.UMD.EDU (Pete Cottrell)
To:        comp.protocols.tcp-ip
Subject:   Re: Honeywell and DG

In article <8805091745.AA24461@ACC-SB-UNIX.ARPA> chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) writes:
>Good morning all!
>	I am going to be running Honeywell and Data General systems on a
>LAN soon and have been told by a customer that they have TCP/IP implement-
>ations running on them.

At one point we had an MV10000 running beta releases of DG's UN*X (DG/UX)
implementation (SYSV-based). We were at level 3.0, I believe. They included 
a TCP/IP implementation and also included the Berkeley r-commands, as well
as NFS. It seemed to work, although it seemed as though the ethernet board
would veg out every once in a while. Since the machine was never really
heavily used, and we had no source for the beast, we never really dug into
the problem. Towards the end of its stay here, we went to 3.1 level of DG/UX
and soon after got rid of it for a variety of reasons.
	This was about a year ago. I can't really vouch for how things
stand now, I'm just speaking up to confirm that yes, there is a TCP/IP
implementation for Data General machines, available from them, at least 
under DG/UX.

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 20:24:00 GMT
From:      darrelj@sdcrdcf.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

In article <880510-175117-10169@Xerox> RMRichardson.PA@Xerox.COM writes:
>> One thing no-one has mentioned yet is the case where the ethernet type is
>> a valid 802.3 packet length.  I think Xerox PUP falls in to this catagory
>PUP -- PARC Universal Packet
>It means you can't talk PUP to hosts that act that way.  One way around 
>this is to change the PUP type numbers to outside the valid length range.  
>This means all the PUP speakers on the net must all do this or you will 
>have split the net into two types of PUP speakers who can talk to only 



It turns out PUP (and its companion address translation-private ARP type) are
the only protocol numbers which conflict with 802.3 length.  The new type
numbers for 802.3 compatibility are 2048 (decimal) higher than they were,
i.e.
PUP is 2560(dec) or 0x0a00
PUP ARP is 2561(dec).
PUP has endured past its experimental days because of an installed base of
hardware which have come to depend on its services.  One of the features of
most PUP protocols which is both a benefit and a drawback is a slight
blurring of the line between layers (in the interest of bit efficiency to
ensure most useful interchanges fit a single 576 byte MTU packet).
-- 
Darrel J. Van Buer, PhD; unisys; 2400 Colorado Ave; Santa Monica, CA 90406
(213)829-7511 x5449        KI6VY        darrel@CAM.UNISYS.COM   or
...{allegra,burdvax,cbosgd,hplabs,ihnp4}!sdcrdcf!darrelj

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 20:59:08 GMT
From:      mark@applix.UUCP (Mark Fox)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: Plenum-Rated Ethernet Transceivers

In article <859@wright.EDU> jsloan@wright.EDU (John Sloan) writes:
>I've seen references on the net to plenum-rated ethernet transceivers [etc.]
>
>...Does anyone have specific recommendations...

When we first installed our Ethernet cable above our dropped ceiling we
also had trouble getting info from fire & building officials. However,
we were assured (not sure by whom -- it was 4+ years ago) that it was
ok from a legal standpoint to install normal yellow PVC cable in plenums
as long as smoke detectors were also present (in the plenums). It certainly
is cheaper than installing Teflon cable or using metal conduit (at least
in the absence of fire!)

Anybody know if this is true today? Any specific building/fire code references
available? Thanks.
-- 
                                    Mark Fox
       Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300
                    uucp:  {ames,rutgers}!harvard!m2c!applix!mark

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 22:01:52 GMT
From:      dick@ccb.ucsf.edu.UUCP
To:        comp.protocols.tcp-ip
Subject:   DACU wanted (used)

The Computer Center at UCSF would like to buy a second IBM 7170-DACU
to back up the existing box.  Perhaps later we will be able to choose
an effective replacement with better throughput and lower overhead.
For now, we wish to feel secure that our Ethernet access is reliable.

If you have replaced your DACU, we would like to know what you chose
and why you chose it.  Please let us know if you would be willing to
part with the DACU, and under what terms.  Please respond by mail or
call me at (415) 476-4529 or Ian Tuller at (415) 476-5097.

Thanks,
   Dick
Dick Karpinski  Manager of Minicomputer Services, UCSF Computer Center
UUCP:  ...!ucbvax!ucsfcgl!cca.ucsf!dick        (415) 476-4529 (11-7)
BITNET:  dick@ucsfcca or dick@ucsfvm           Compuserve: 70215,1277  
USPS:  U-76 UCSF, San Francisco, CA 94143-0704   Telemail: RKarpinski   
Domain: dick@cca.ucsf.edu  Home (415) 658-6803  Ans 658-3797

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 May 88 23:30:41 GMT
From:      stjohns@beast.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   controlling IP "type of service"

Dave, by TOS, do you also mean the precedence bits?

Mike

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 00:46:18 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Password transmission and encryption query

Vince,

You might be interested in the way Defense Data Network will be
handling a similar problem.  Classified users will employ end-to-
end encryption to protect their data.  This is in addition to any
link (aka bulk) encryption of the links.  Each classified user is blessed
with a gadget called a Blacker front-end device (KOI-111).

If you and Ivan want to hold a session over the net, you compare
keys on connection-open to see if you can talk at the required
level of classification.  If you can't, your host fires off a message
to the authentication host (somewhere 'out there') who validates
your clearance level and need to know.  Assuming you are OK to
conduct this session, the authentication node sends an enabling
message to the key control host (also 'out there') who then
proceeds to issue keys to you and Ivan and off you go.

When you are done, the keys can be made to evaporate (consider all the
crypto custodian grunt labor and insecurity this gets rid of).

I believe the key distribution process makes use of the RSA
algorithms, but not sure.

There are other complementary parts of this larger system.  The
trusted computer security standards for this will be top-drawer,
(A1 in Orange-book-ese).  Also the classified portion of DDN
will be segregated from the unclas side (and all the rest of us
out in net-land) probably forever.

Rex Buddenberg
USCG Headquarters

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 01:25:05 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Mike,

You're gonna love this: The queues are ordered by precedence; however, in
case of TCP and either the source or destination port fields are TELNET,
then assume a precedence of one. E pluribum unicorn and pass the rsh sauce,
please.

Dave

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 01:31:15 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Mike,

I lied and even misrepresented my own code. The queues are ordered by the
value of the entire 8-bit TOS octet, including both precedence and DTR bits.
In case of TCP and either source or destination port fields are TELNET,
behave as if the D (delay) bit is set. Note the precedence bits are at
the high-order end, so my previous message is morally right but factually
inaccurate. What the heck, close enough for academic work.

Dave

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 May 88 09:36:25 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Third TCP-IP Book?

IEEE Computer has an ad by Springer-Verlag which beyond listing
Davidson's book, also mentions

    The Complete Guide to TCP/IP Protocol Suite
	by Don Huntington and George Cohn
	due out in 1988.

I don't know either author and they aren't in the NIC table.  Anyone
heard anything about this book?

Craig
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 04:58:30 GMT
From:      andrew@riddle.UUCP (Andrew Beattie)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Competition for Bridge

Does anyone other than Bridge make Ethernet TCP/IP Terminal servers?

(A bit of healthy competition might help their price policy :-) )

Mail me, and I'll post a summary.

Many thanks.

Andrew Beattie
Sphinx, 43-53 Moorbrige Road, Maidenhead, England
mcvax!ukc!reading!riddle!andrew
andrew@sphinx.co.uk
+44 628 75343
#include <disclaimer.h>

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 05:11:00 GMT
From:      zweig@uiucdcsp.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Password transmission and encryptio


	The best and most common solution I know of is to have ``boring''
accounts that accept anonymous FTP (witness sri-nic et al.) so nobody
cares who listens in to passwords. :-) If it's worth protecting, it's
worth hiding from rlogin's and ftp and that sort of thing, isn't it?


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

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 May 88 10:10:16 EDT
From:      KASTEN@MITVMA.MIT.EDU
To:        jqj@hogg.cc.uoregon.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Dumb vs. smart host routing

>  Similarly, I claim that we will need some sort of discovery mechanism
>if the list of gateways on a local network is expected to be large and
>dynamic.  We have such a discovery mechanism in place today; passive
>RIP.  I'm not recommending that we improve it, or that hosts use it for
>anything except finding the first gateway.

UNfortunately, not all of the systems that use IP are (easily) capable of
running a RIP listener. PC's are the best example - they do not have
multitasking, making it difficult to load in a program to listen to the
RIP traffic. There are ways of doing it but this is not a forum for
discussing PC stuff.

>I believe that a gateway can be taught to send out RIP packets saying
>"I'm a default router" without sending out any other data.  If so, this
>would provide my desired discovery mechanism with no changes to a
>common flavor of host software (i.e. BSD derivatives).

Not all of us are so lucky as to have a BSD system available on which
we can build our stuff.

I like the idea of the "I am a Router" broadcast's. The problem, again,
is that not all hosts may be capable of listening at all times for that
broadcast (even a BSD machine could be turned off). Instead, a query and
response type of protocol could be used. When a host needs to send
something off net and either A) does not have the IP Address of any
router (if it had one address, it could send a packet to that router
and get the redirect) or B) the host decides that the router it is
using is dead (e.g. TCP has retransmitted too often) then the host
broadcast a "Who can route to network X?" request and the routers on
the local network would respond. This would require changes to both
routers and hosts, but I think is the most flexible over the widest
range of hosts - from the single "tasked" PC's up to Crays. Of course,
you still can listen to RIP (but what if the routers want to use
another protocol?)

Frank Kastenholz
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 06:22:54 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

In article <10285@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven Bellovin) writes:
>One problem I see is that ICMP Redirect is largely useless.  It's only
>useful for the first gateway along the way to tell the originating host
>to use a different gateway; it can't be used to tell an intermediate
>gateway what the proper next hop is.

But that's not really a problem with ICMP redirects at all. Look at it
this way:
	ICMP redirects are the (okay, *a*) way routers communicate routing
	information to hosts

	XYZ (fill in your favorite routing protocol(s)) is the way
	routers communicate routing information to one another.

If the routers are doing their job properly then the routers on the
same subnet as the host will redirect it to the proper router via
ICMP; this router will then do XYZ things to figure out how to route
the packet from there. It's because of XYZ that the routers know when
to redirect in the first place.

>The conclusion of all this is that local gateways must be extremely
>smart.  The current scheme, with EGP, works well enough in the current
>environment, where there's one central net (ARPANET+MILNET); it would
>fail miserably if there were a large number of interconnected backbone
>nets.
>
>I'm not certain what to do about the problem.

The example assumes that the routers are screwed up in the first
place. You don't necessarily have to have an incredible amount of
information in your routers that are used by your host - you just have
to have routing protocols that do the right thing (which may actually
require incredible amounts of information...oh well).

The thing to do about it is to refine the XYZ protocols (ancient GGP,
RIP, EGP) so that they work better for larger, more complicated
networks. Yes, the current system doesn't deal with complicated
networks very well. It doesn't handle redundant routes well. It
doesn't handle load-sharing very well. It doesn't route on Type of
Service very well (because not a lot of routers support it and
virtually no hosts set the TOS field in the IP header).

I believe there are people on an IETF task force or working group or
some such working on this problem.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 May 88 12:56:48 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        Mike Marshall <hubcap@gatech.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Doug Comer's TCP/IP book...
I read HCCS Vol 3 (By William Stallings - ISBN 0-02-948072-8, MacMillan)
and found it to be a good "My First TCP Book" for some technical type of
person who is trying to get into the game. It is too much for the non-techie.

Haven't read Comer's book yet.

Frank Kastenholz
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 13:19:00 EDT
From:      <yurcik@nrl-lcp.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        yurcik
Subject:   TCP-IP Book of the Month Club

	I also recommend Doug Comer's book.  Free enterprise
	seems to be at its best by giving the network people what they
	want and creating what I believe will be a major new topic area
	in the technical book market.   

	I have become aware of another book, "The Complete Guide to TCP/IP" 
	by Don Huntingdon & George Cohn soon to be released by Springer-Verlag,
	NYC, NY.  Can anybody comment on its content?  Are the authors out 
	there?  Any others thinking about becoming an author?


	Bill Yurcik
	"yurcik@nrl-lcp.arpa"
	
	

------
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 15:59:30 EDT
From:      MIKEC%csp-a.prime.com@RELAY.CS.NET
To:        TCP-IP@SRI-NIC.ARPA
To:       (smb@ulysses.att.com)
Cc:       (tcp-ip@sri-nic.arpa)
From:     Michael A. Curtis (mikec@csp-a.prime.com)
Date:     13 May 88  3:40 PM
Subject:  Re: Smart vs. dumb host routing

Steve,

     I think you've missed the whole point of the issue.  That is the exact
intent of ICMP in this case.  Once the host delivers the packet, its job is
over and if it is sent to the wrong default gateway for the destination
network chosen, then an ICMP (*HOST*) redirect should be issued telling the
host which gateway is the correct one to deliver future packets for that
network to.

     Further, once the gateway has the packet, ICMP is out of the picture as
all gateways should have up-to-date knowledge as to what the topology
currently looks like via a routing protocol such as RIP.  There should be
absolutely no indecision as to whether it should deliver the packet to G'
or G'', etc. and no need for ICMP redirects to be flying around.  Also, EGP
probably has no bearing at this point as the discussion has been focusing on
the problems/advantages of subnets with different size masks, thus the traffic
would be internal to the AS and EGP doesn't know about subnets anyway!

     As a separate discusion, we can talk about the merits of having a
different subnet mask on a per interface basis in a gateway as discussed
in RFC1009.  To my knowledge, no one is implementing this.  Does anyone know
of any plans?


-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 13:36:25 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Third TCP-IP Book?


IEEE Computer has an ad by Springer-Verlag which beyond listing
Davidson's book, also mentions

    The Complete Guide to TCP/IP Protocol Suite
	by Don Huntington and George Cohn
	due out in 1988.

I don't know either author and they aren't in the NIC table.  Anyone
heard anything about this book?

Craig

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 14:10:16 GMT
From:      KASTEN@MITVMA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing


>  Similarly, I claim that we will need some sort of discovery mechanism
>if the list of gateways on a local network is expected to be large and
>dynamic.  We have such a discovery mechanism in place today; passive
>RIP.  I'm not recommending that we improve it, or that hosts use it for
>anything except finding the first gateway.

UNfortunately, not all of the systems that use IP are (easily) capable of
running a RIP listener. PC's are the best example - they do not have
multitasking, making it difficult to load in a program to listen to the
RIP traffic. There are ways of doing it but this is not a forum for
discussing PC stuff.

>I believe that a gateway can be taught to send out RIP packets saying
>"I'm a default router" without sending out any other data.  If so, this
>would provide my desired discovery mechanism with no changes to a
>common flavor of host software (i.e. BSD derivatives).

Not all of us are so lucky as to have a BSD system available on which
we can build our stuff.

I like the idea of the "I am a Router" broadcast's. The problem, again,
is that not all hosts may be capable of listening at all times for that
broadcast (even a BSD machine could be turned off). Instead, a query and
response type of protocol could be used. When a host needs to send
something off net and either A) does not have the IP Address of any
router (if it had one address, it could send a packet to that router
and get the redirect) or B) the host decides that the router it is
using is dead (e.g. TCP has retransmitted too often) then the host
broadcast a "Who can route to network X?" request and the routers on
the local network would respond. This would require changes to both
routers and hosts, but I think is the most flexible over the widest
range of hosts - from the single "tasked" PC's up to Crays. Of course,
you still can listen to RIP (but what if the routers want to use
another protocol?)

Frank Kastenholz

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 14:45:48 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing

The OSI approach to this problem is to use the End System-Intermediate
System protocol (ISO 9542).  In this scheme the ES's (hosts) and IS's
(routers) periodically multicast "hello" packets to one another in order
to determine reachability.  The period used can ultimately be controlled
by the IS's.  This usually means that address mapping info is already
cached so the "hold on a minute while I find out where this packet
needs to go" approach that ARP uses is most often not needed.
 
Hosts will discover all routers on the subnet using this mechanism.
Redirects are used to teach the hosts which routers to use for
particular addresses.  The redirects can contain address masks defining
equivalence classes of destination addresses to redirect, as well as
possibly hinting that the host can algorithmically derive the MAC
layer address from the network layer address (OSI NSAP addresses are
big enough to embed MAC addresses in them if somebody wants to).
 
This protocol is purposely decoupled from IS-IS routing ("IGP") with
the philosophy that hosts should be kept insulated from the details
of what happens in the routers, and should be kept simple.  Thus the
only a priori information needed is the ES's own address.
 
This obviously doesn't help in the TCP/IP world, but it's worth
mentioning.
 
  --Dave Katz
    Merit Computer Network/NSFnet
    Dave_Katz@UM.CC.UMICH.EDU

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 15:20:30 GMT
From:      rcsmith@anagld.UUCP (Ray Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain telnet/ftp


In article <1307@ntmtka.UUCP> you write:
>I have been asked by an acquaintance from another company (without access to
>Usenet) to find out if there are public domain versions of Telnet and FTP
>for Unix.  ...
>Replies can either be posted or emailed directly to me.  Thanks.
>


I am also interested in obtaining public domain Telent/FTP source.
Could you please send me a copy of the information you get?

Thanks in advance,
Ray
-- 
Ray Smith       | USnail: Suite 200, 9891 Broken Land Pky, Columbia, MD 21046
Analytics, Inc. | GEnie : rcsmith
(301) 381-4300  | CIS   : 72000,1111
		| Net   : ...!uunet!mimsy!aplcen!anagld!rcsmith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"The trouble with doing something right the first time is that nobody
appreciates how difficult it was." -Walt West
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 15:54:50 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting [struct Enet addr]

In article <8805100150.AA07641@braden.isi.edu> braden@VENERA.ISI.EDU writes:
>I disagree.  The Internet standard approach for a host: pick any
>gateway and let it redirect you... is simple and effective. You REALLY
>DON'T want hosts to know about routing, even subnet routing!!

	I agree in principle, but in practice we are talking about
hosts on Ethernet LANs with flat address space internetworked on IP
wide area networks with hierarchical address space.  I don't see any
alternative to ARP and gateways.  The host has to know when to look
directly on the flat address spaced LAN and when to hand off to the
gateway for forwarding.

	This brings me to a question I have been dying to ask for a
long time, but just didn't quite know what context to ask it in...

	It seems so obvious to me that a hierarchically structured
address space in Ethernet (read 802.x) 48 bit addresses would be a
great improvement over the current kludged 48 bit flat vendor-assigned
address space coupled with the 32 bit IP address space that I wonder
why the issue never comes up.  I know all the obvious problems with
structured Ethernet addresses, but everytime I look at the issue it
seems to me that structured Ethernet/IP (read 802.x) addresses would
be a great improvement over flat address space.

	I think the 802 spec allows structured addressing, yes?  Why
is there no hint of movement in this direction?  Waiting for ISO?  Or
have I failed to grasp some essential difficulty with this?  Comments,
please.

	Kent England, Boston University

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 16:56:48 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Doug Comer's TCP/IP book...

I read HCCS Vol 3 (By William Stallings - ISBN 0-02-948072-8, MacMillan)
and found it to be a good "My First TCP Book" for some technical type of
person who is trying to get into the game. It is too much for the non-techie.

Haven't read Comer's book yet.

Frank Kastenholz

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 17:14:37 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP

In my humble opinion, IEEE 802.2/3 is yet another standards committee
that the world would have been far better off without. The changes they
made to DIX (DEC-Intel-Xerox) Ethernet, already a well-proven de-facto
industry standard, were utterly gratuitious. The existing 16-bit type
field provided plenty of expansion room to build whatever additional
capability they wanted while maintaining compatibility with existing
protocol encapsulation formats.  The new "length" field not only breaks
compatibility, but is useless, redundant information for the protocols
that already ran on Ethernet since they have their own type fields.
(If a length field was considered necessary for other protocols, it
could have been provided AFTER the type field, and only for certain new
values in the type field).

Because the DIX Ethernet type fields are invalid as 802.3 length values,
it is possible to write packet receiver code that will accept, say, IP
datagrams in either DIX or 802.3 framing, but real problems come when
you need to decide how to SEND packets to another host you haven't
spoken to before.

I see only one easy answer to the gratuitous compatibility problems
imposed by 802.3: IGNORE IT!  Also be sure to tell the manufacturers
why. Maybe someday the standards-mongers will get the message.  (Begin
Bernstein music here) Someday, somehow, somewhere...

Phil

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 17:19:00 GMT
From:      yurcik@NRL-LCP.ARPA
To:        comp.protocols.tcp-ip
Subject:   TCP-IP Book of the Month Club


	I also recommend Doug Comer's book.  Free enterprise
	seems to be at its best by giving the network people what they
	want and creating what I believe will be a major new topic area
	in the technical book market.   

	I have become aware of another book, "The Complete Guide to TCP/IP" 
	by Don Huntingdon & George Cohn soon to be released by Springer-Verlag,
	NYC, NY.  Can anybody comment on its content?  Are the authors out 
	there?  Any others thinking about becoming an author?


	Bill Yurcik
	"yurcik@nrl-lcp.arpa"
	
	

------

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 17:27:33 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Dumb vs. smart host routing

You are right in that ICMP redirects are only good in indicating the
first hop from a host.  But that does not make them largely useless,
since this is their intended use, and is a valuble part of not
requiring hosts to understand complicated routing.  This way a host
only needs to know about one local gateway *which is currently
functioning* and redirects will do the rest.

Gateways, on the other hand, must understand routing within their own
autonomous system, and to other systems.  It is expected that gateways
will make use of other protocols for this, not try to use ICMP for
something it was not designed for.

As in the discussion about how hosts find out about the different
first-hop gateways available: the hosts shouldn't listen to RIP, a
gateway routing protocol, just as gateways don't for the most part
receive ICMP redirects.  We will get nothing but trouble if we try to
use the same protocols between gateways and for hosts to communicate
with gateways.  A gateway-to-gateway protocol is necessarily going to
be much more complicated than what a host needs, and *will* evolve
over time as the internet grows.  It should be possible to specify a
gateway-to-host protocol in such a way that it is simple and not
likely to change so that it will get implemented by all vendors for
all operating systems.
					-Mark Rosenstein

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 17:29:47 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Davidson's book vs. Comer's book

In article <880512092448.2260d215@Csa4.LBL.Gov> forrest@LBL.GOV writes:
>is why I turned to Comer's book. Comer's book is MUCH better although some
>of the chapters (specifically those dealing with routing) didn't feel right.
>This is probably my fault and I intend to reread the whole book a second time.
>
No, I felt the same way.  The chapter on routing is too brief and left
me wanting more.  We need still one more book that tackles some of the
issues Comer left too briefly treated.  Maybe it's too soon.  For now,
it's back to the RFCs and IDEAs.

	Kent England, Boston University

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 19:20:35 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing


    Date: Thu 12 May 88 14:38:09-EDT
    From: John Romkey <ROMKEY@xx.lcs.mit.edu>
    Subject: Re:  Dumb vs. smart host routing
    To: jqj@hogg.cc.uoregon.edu
    Cc: tcp-ip@sri-nic.arpa
    
    [ ... ]
    I envision networks where links to other networks come and go, but not the
    actual routers themselves. It's a strange idea to me. I don't see any
    application for it off the top of my head.

On our network, which is fairly real-worldish, we have a uVAX-II with
very flakey dequna board.  It panics several times a day, leaving us with
an alternative route but no way to know about it.  Your vision could be
a little broader, without going over your head. :-)
    
    [ ... ]
    of one default router; I'd like to increase it to an arbitrary list of them
    which is cycled through for reliability. If you have only one default router

Won't this affect your TCP RTT and cause some sort of oscillation (or force
you to bind connections to routes)?

-Philip

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 19:59:30 GMT
From:      MIKEC@csp-a.prime.COM
To:        comp.protocols.tcp-ip
Subject:   (none)

To:       (smb@ulysses.att.com)
Cc:       (tcp-ip@sri-nic.arpa)
From:     Michael A. Curtis (mikec@csp-a.prime.com)
Date:     13 May 88  3:40 PM
Subject:  Re: Smart vs. dumb host routing

Steve,

     I think you've missed the whole point of the issue.  That is the exact
intent of ICMP in this case.  Once the host delivers the packet, its job is
over and if it is sent to the wrong default gateway for the destination
network chosen, then an ICMP (*HOST*) redirect should be issued telling the
host which gateway is the correct one to deliver future packets for that
network to.

     Further, once the gateway has the packet, ICMP is out of the picture as
all gateways should have up-to-date knowledge as to what the topology
currently looks like via a routing protocol such as RIP.  There should be
absolutely no indecision as to whether it should deliver the packet to G'
or G'', etc. and no need for ICMP redirects to be flying around.  Also, EGP
probably has no bearing at this point as the discussion has been focusing on
the problems/advantages of subnets with different size masks, thus the traffic
would be internal to the AS and EGP doesn't know about subnets anyway!

     As a separate discusion, we can talk about the merits of having a
different subnet mask on a per interface basis in a gateway as discussed
in RFC1009.  To my knowledge, no one is implementing this.  Does anyone know
of any plans?

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 20:16:09 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

Well, I might as well throw some more ideas into the fire.  At cisco
(where we make routers), we also believe that hosts should know nothing
about routing protocols.  This becomes much more obvious when your router
is running 4 different routing protocols simultaneously, and translating
metrics from one to another is both difficult and dangerous.

Of course, it ought to be possible to use any of the gateways you've
learned about via redirects as new default gateways, but this is probably
not easy to add to existing code.  However, John Romkey said:

    If some new protocols were cooked up to allow hosts to query routers
    for some useful information WITHOUT the hosts understanding how the
    routers worked, that would be okay as far as I'm concerned.

We believe that such a protocol already exists which provides this
function, and is implemented by nearly all tcp/ip vendors.  It is called
ARP.  A router can respond to ARP requests that it recognizes as being for
hosts not connected to the local cable if it knows a route to that network.
This technique is being called "Proxy ARP", and is frequently used to make
subnetting transparent to hosts.  It works equally well to make any network
topology transparent to hosts.  Redundancy is handled automatically if you
convince TCP and other high level protocols to flush ARP entries when they
are about to time out.

Of course, this only works with hosts on networks where ARP is used for
address resolution (broadcasts are possible).  But if a host has only a
point-to-point link to the network, it might as well use whatever gateway
is at the other end of that link as its default gateway.  This leaves only
networks like X.25 and the ARPANet (non-broadcast, but not really point-to-
point either), and it might not be such a bad idea to have those hosts know
about routing, at least to the extent of having multiple default gateways.

Bill Westfield
cisco Systems.
-------

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 20:42:06 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Plenum-Rated Ethernet Transceivers

In article <696@applix.UUCP> mark@applix.UUCP (Mark Fox) writes:
>we were assured (not sure by whom -- it was 4+ years ago) that it was
>ok from a legal standpoint to install normal yellow PVC cable in plenums
>as long as smoke detectors were also present (in the plenums). It certainly
>is cheaper than installing Teflon cable or using metal conduit (at least
>in the absence of fire!)
>
>Anybody know if this is true today? Any specific building/fire code references
>available? Thanks.

We went through all this, too, and in Boston there are code provisions
for allowing PVC [non rated] cable in return air plenums when there
are smoke detectors tied into the air handling system that shut down
the air circulation in the event of fire.

Unfortunately, there is no relation between Boston codes and state of
Mass codes and national codes, since it is possible for the state and
city to override and change any provision of the national codes.  You
MUST verify compliance to code for each and every building project
with the inspectors, they have the last word.

When talking to your architects and general contractors, ask for an
air handling system that does not require fire rated cable.  Leave it
to them to figure out how to do it.

	Kent England, Boston University

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 May 88 20:49:13 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip
Subject:   Re: another TCP/IP book

John Davidson's book, An Introduction to TCP/IP is exactly that, an
introduction.  As such, it is likely to be less involving and intimidating than
Doug's book for someone who would rather read a quarter inch of paper and know
something than to read an inch of stuff.  It's likely that most netters have a
sufficient interest in TCP/IP to warrant choosing Doug's book, which looks
excellent, though I haven't read it yet.  But many netters, and perhaps the
majority of TCP/IP users in general, might be better served by a shorter
overview of TCP/IP, such as John's book.  The bad news is that they apparently
cost about the same, even though John's book is a quarter inch softback.  Oh,
well...

-bc
-- 
Bill Crews                                   Tandem Computers
bc@halley.UUCP                               Austin, Texas
..!rutgers!im4u!halley!bc                    (512) 244-8350

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 02:13:06 GMT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing

> On our network, which is fairly real-worldish, we have a uVAX-II with
> very flakey dequna board.  It panics several times a day, leaving us with
> an alternative route but no way to know about it.  Your vision could be
> a little broader, without going over your head. :-)

Originally we were discussing 'extremely dynamic' router changes. A crash
every few hours doesn't cut it with me for 'extremely dynamic'. There
are two things that should be done here. First, the microvax should be fixed.
Second, the software should have the list of default gateways that I keep
bringing up rather than just one.

> Won't this affect your TCP RTT and cause some sort of oscillation (or force
> you to bind connections to routes)?

Not a problem at all. You cache a route for each connection; if the
connection starts having problems or an appropriate redirect is
received, you recompute the route. It's very simple and quite efficient
if implemented correctly.
					- john
-------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 03:45:44 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Mike,

Its been a while since I've read the RFP.  Is Dave trying to say that a
CRITIC is less important than a Flash or Flash Override?

Merton

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      14 May 1988 08:35-EDT
From:      CERF@A.ISI.EDU
To:        Mills@LOUIE.UDEL.EDU
Cc:        stjohns@BEAST.DDN.MIL, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  controlling IP "type of service"
Dave,

does the precedence queueing inyour Fuzzballs account for some of 
the very long-delayed packets showing up in the Internet from
time to time? Under heavy load, unless you have a time-dependent
priority system, some packets may stay in queue quite a while as
higher precedence traffic goes by.

Vint
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 06:19:56 GMT
From:      haque@dg.cs.umn.edu (Samudra E. Haque)
To:        comp.protocols.tcp-ip,comp.misc
Subject:   TCP/IP implementations for DG/UX on MV series Hardware (was Honeywell and DG)

>From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
>Date: 9 May 88 17:45:19 GMT
 
>>    I am going to be running Honeywell and Data General systems on a
>>LAN soon and have been told by a customer that they have TCP/IP implement-
>>ations running on them. Does anyone have any comments, suggestions, war
>>stories or anything else that relates to these implementations? I have never

I run a MV10000 machine with Data General native unix here at the 
Computer Science Laboratories, current revision of the OS is 3.11 and
revision of the TCP/IP portion is 2.1 I believe. 

Summary of TCP/IP on DG machines: not bad, but could be better.

You might want to be aware of a couple of things "peculiar" or "unique" 
to Data General Unix software: 

    Disclaimer: Your mileage may vary in proportion to the relation you
    have with the company and its sales offices.

    a) There ARE people directly connected with Data General on the
    net and who have access to this and other newsgroups. Maybe they'd
    like to publicise their own product some day? [Dg-Rtp people:With
    the recent Unix announcement by De Castro, don't you think your 
    management would love a few extra customers? :-) ]

    b) Currently DG has several TCP/IP packages with different O/S's: 
            AOS/VS with MV/UX (Unix) as a sub-process.
            DG/UX native Unix (SVID compatible System V/BSD 4.2)

        We used to have AOS/VS at our site but about 9 months ago
        switched over to DG/UX. While the cutover itself was painless,
        and while DG/UX makes our machine a far better and useful CPU
        on the whole, lack of good networking utilities hampered us a
        bit. Also something that really hurt us was the "inability"
        for DG/UX to communicate with certain vendor machines
        including other MV series machines themselves. 

        Some of these problems are currently under going investigation
        (Data General has a very good customer support service at
        least), but here are a few details:

            1) Most of the code for the TCP/IP version 2.1 coupled
            with DG/UX 3.11 were written in 1985 or 1986. code
            currently is predominantly based on 4.2 code with *ALL* of
            the bugs still present.

            2) No nameserver support.

            3) Occasionally some of our SUN-2's and SUN-3's will not
            be able to communicate with the MV and vice-versa.

            4) I find it impossible to work from an MV10000 <->MV20000 
            over the arpanet using DG/UX 3.11 and TCP/IP. Connections
			will inevitably hang or refuse to start at all.

            5) In one nasty case, we found that they had ('as a result
            of a design decision in previous revisions ') written parts
            of the O/S code that relied on a particular level of 
            revisions of the boards inside the CPU including the ILC 
            (intelligent lan controller).  What would happen if you 
            weren't running that particular level was that occasionally 
            (read: randomly) there was the possibility of a board being 
            *IGNORED* by the CPU.  Only a hardware reset would bring that 
            board back up!

            There was no fix except to *up* the hardware, and if it happens
            again I'm tearing somebody's desk in half.

    b) Things ARE going to change: (All for the better I hope)
        1) revision numbers are going to be standardised. Thus DG/UX
        revision 4, due out mid summer is going to have TCP/IP rev 4.

        2) nameserver support will be provided. 

        3) new code fixing trailing headers and other  problems 

    The reason for this change in progress is the advent of DG/UX
    revision 4: (100% system V and 80-90% BSD, according to sales
    reps). Data General wants to get into the Unix market with a
    stronger line of products and hence it has just recently increased
    support of DG/UX internally. Overall I have heard DG/UX revision 4
    to be a worthwile operating system.

    c) Currently DG/UX has neat stuff like NFS/YP (we use NFS, but not
    YP) pretty good implementations, except for lacking in symbolic
    links (fixed in rev 4 of course). It has also the standard BSD 'R'
    functions : rsh/rlogin etc. etc.

    Programming with TCP/IP isn't that bad from my limited experience
    with it, ( I ported RRN at least) like any other piece of software
    that is to exist in a hybrid environment the following apply:

            1) If you use system independent packages (i.e. curses and
            not terminfo) software will tend to port easier.

            2) If you really really REALLY want to break a piece of
            software - you will be able to. 

            3) Rtfm,rtfm, RTFM!

    d) Corporate Software support is good now from the customer support 
    center in Atlanta, GA - but it could be a lot better. It used to be until
    a few weeks ago that the first level reps would not know the
    remotest Unix type questions even if you told them the page number
    of the manual to look at. Again, with the turn towards unix, more
    and more staff are taking Unix classes. (I can just see it now:
        "you mean if I do a 'ls' it will print out the same
        information as the DIR command in AOS/VS? ":-)

    If they (DGC software problem management dept), happen to fix a bug, 
    then often times they will give you binaries of all the programs 
    ($22,000 for source code if you are inclined to buy it) and they won't 
    even provide the *.o modules for convinience. That means of course you 
    *have* to be upto date with the software revisions. 


Other than that - I don't have much to say. (i've already said enough
don't you think?). Again, it's raining now but the outlook for the future 
is clear and getting warmer. Oh, I think 75 F, and 35% humidity please..


Cheers!

                          Samudra E. Haque
    Computer Science Laboratories, Computer Science Department
         University of Minnesota, Minneapolis, MN 55455
(1)-(612)-625-0876 || haque@dg.cs.umn.edu || umn-cs!haque%dg.cs.umn.edu

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 12:35:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Dave,

does the precedence queueing inyour Fuzzballs account for some of 
the very long-delayed packets showing up in the Internet from
time to time? Under heavy load, unless you have a time-dependent
priority system, some packets may stay in queue quite a while as
higher precedence traffic goes by.

Vint

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 16:10:36 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing

Binding connections to routes is not necessarily bad.  Binding connections
to routes will probably be a necessity if, and when, multi-level security
is implemented.  Not all gateways, hosts, etc. may be accredited to service
a transmission at a given security level.  Which we lead to some requirement
for a node to be able to request of each node in a path "can you provide me
this class (type) of service at this security level?"

Merton

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 17:06:41 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Third TCP-IP Book?

The supposed "Complete Guide to TCP/IP ..." will not be out this
spring.  I talked to one of the purported authors about it
this week and he said that he had to back out of th eproject
because of overload, but that the project was still being pursued.
I did'nt get a date, but my reading is summer/fall.  All these books
on TCP/IP are wonderful.  Finally we have something(s) to give to people
that expalins what we have been doing for the past decade.  I have reviewed
all three extant books and each has it merits and faults.  I may as well
go on record, so to speak, about my views on them to help others decide
which to get for which purpose.  These views are my own (who else???).

Comer's book is extremely thorough on the lower layers (up through TCP).
It gives an outstanding exposition of th eneed for internetting and addresses
the common and ugly cases in a clear style.  An excellent book for the
technically inclined.  This book is weak on the application protocols.It
explains them, but does not delve very deeply into them.

Stalling's book is very thorough on the application layer protocols and
not very strong on the lower layers.  I think of it as trying to 
explain Ip and TCP from an ISO viewpoint.  While technically clean,
it lacks motivation.  

Davidson's book is good material to give to a marketing person.  It explains
al the terms, much of the history, and does not dig too deeply.  It is
a short book (around 100 pages) and is essentially an annotated glossary.

So, all three books have their place.  

Dan
-------

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 19:10:56 GMT
From:      len@spam.istc.sri.COM (Len Schlegel)
To:        comp.protocols.tcp-ip
Subject:   Synchronous input performance question


Forgive me if this question is inappropriate for this group.

In unix systems it seems that you can block awaiting input on some socket in
two ways.  Either you use a blocking socket and then read (or block at
a select call) and continue when input arrives, or have your
socket set so that a SIGIO is generated when input arrives, at which
point you do your read (or select) in your signal handler.  The blocking
can be achieved by using the sigpause call.  In the later case, the socket
can be non-blocking.
	The question is are there performance implications in using
one approach over the other.  

Thanks,

Len Schlegel
len@spam.istc.sri.com

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 20:04:16 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Merton,

I takes the bits as they come. All ones is the greatest and all zeros
the least most mortals could aspire. I plead resistant to any semantic
exercise that attempts to match Internet reality with Precedence mappings.

Dave

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 20:22:03 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Public domain telnet/ftp

Are there vendors that provide TCP/IP without FTP/TELNET?

If so, you need a hell of a lot more than just FTP to do anything.

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 20:34:01 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Vint,

Verily in an FB(n) system dudes at higher priority levels can freeze
out dudes at lower priority levels if the volume of traffic at the
higher levels is sufficiently intense. There is now doubt that this
occasionally occurs when the NSFNET Backbone is sore abused by certain
4.2bsd systems that have not upgraded to 4.3bsd with the Jacobson/Karels
pollution controls (point made - I have not yet found a way to reliably
identify 4.2bsd abusers and stamp their passports with priority zilch).
While the freezees can shiver in the queues as the hotrods whiz by,
they can't freeze for longer than their TTL, for most systems not
over thirty seconds and for no systems longer than about four minutes.
What usually happens is that, a packet below the eutectic can't live
more than a few seconds before being preempted anyway. Such is live
in the present 56-kbps world.

Fancier schemes can readily be proposed to improve fairness with FB(n)
systems, many of which were first proposed in the CTSS days when
timesharing was losing its hyphenation. In context of six weeks the
existing 56-kbps backbone is to live before being retired hy the
new 1.5-Mbps backbone, there is small chance that these schemes will
be implemented. There may be at least a month before the new backbone
will have to face the same problems.

Dave

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 20:39:42 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Excelan and subnets

Does Excelan's TCP/IP for MS-DOS support subnets yet?
The version I have (EXOS 8051-02 Ver 3.2.5 Rev B) does
not.  My sales critter isn't sure what RFC950 subnetting
is and I don't think I'm going to get an answer from him.

Are there any other good reasons to upgrade?

Jim Warner  **  408-429-2606
University of Ca Santa Cruz

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      14 May 88 22:25:47 GMT
From:      oconnor@sccgate.scc.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on TCP/IP book wanted

Any points for noting the mistake on page 40?

		Mike

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 00:47:14 GMT
From:      jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

>                                       ...When a host needs to send
>something off net and either A) does not have the IP Address of any
>router (if it had one address, it could send a packet to that router
>and get the redirect) or B) the host decides that the router it is
>using is dead (e.g. TCP has retransmitted too often) then the host
>broadcast a "Who can route to network X?" request and the routers on
>the local network would respond.

	Now be VERY careful with protocols that broadcast questions
that may get simultaneously answered by a large number of machines. In
a network with only one or two routers what you suggest would work
fine. However when you have about 20 routers on an Ethernet you are
likely to get a monster Ethernet collision when they all go to respond
to the broadcast. There have been several horror stories posted to
this mailing list of "monster collision" problems (I know, I was one
of the senders!). ARP works using broadcast questions, but in a
properly functioning network exactly one machine should respond, so no
collision.

	However you do bring up a problem with single threaded
machines. What if we modify your scheme so that all routers on a
network speak some (as yet undefined) protocol to elect one of them
the "advertised default router" and only this router would respond to
the "Who can route" message. If this router went down the other
routers would know and elect a new default router. [Note I have
simplified the question from "Who can route to network X?" to just a
simple request for a default router. That router can then send
redirects later when packets arrive.]

			-Jeff

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 01:00:11 GMT
From:      geoff@fernwood.mpk.ca.us (Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Mail Order TCP-IP.

What with three books available or soon to be on TCP-IP, take note in the latest
Black Box Catalog... TCP-IP is now available via mail order.  Diners Club
International, Carte Blance, Master Charge, American Express and Visa accepted!
From a PDP-11/20 via a Very Distant Host connection to SRI from Vint Cerf's Lab
at Stanford to a mail order house & just about every plastic charge plate.
TCP-IP has (almost?) become a consumer item.  Next stop.... Radio Shack?
Geoff

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 03:43:12 GMT
From:      bzs@bu-cs.bu.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Synchronous input performance question


>In unix systems it seems that you can block awaiting input on some socket in
>two ways.  Either you use a blocking socket and then read (or block at
>a select call) and continue when input arrives, or have your
>socket set so that a SIGIO is generated when input arrives, at which
>point you do your read (or select) in your signal handler.  The blocking
>can be achieved by using the sigpause call.  In the later case, the socket
>can be non-blocking.
>	The question is are there performance implications in using
>one approach over the other.  

You'd probably do well directing questions like this to
unix-wizards@sem.brl.mil (I think that's the appropriate host name.)

Doing the read alone is clearly lower overhead as the signal mechanism
requires several things to happen as well as the ultimate read, you
pay what you get for. Whether it's "high" or "unacceptable" overhead
is an entirely differnet question and depends on the motivation which
brought the question up. If you were doing nothing but looping in data
I can't see any reason to incur the signal overhead. If you sometimes
needed the non-blocking behavior than you have a reason to do that,
etc etc.

	-Barry Shein, Boston University

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 06:29:14 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting [struct Enet addr]

In article <22596@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>	I agree in principle, but in practice we are talking about
>hosts on Ethernet LANs with flat address space internetworked on IP
>wide area networks with hierarchical address space.  I don't see any
>alternative to ARP and gateways.  The host has to know when to look
>directly on the flat address spaced LAN and when to hand off to the
>gateway for forwarding.

Easy. If your host has only one network interface, then just do this:

if((my_ip_address & my_subnet_mask) == (dest_ip_address & my_subnet_mask))
	first_hop = dest_ip_address;
else {
	first_hop = default_routers[next_default_router++];
	next_default_router %= number_of_default_routers;
	}

Then send the packet to the IP address on your physical network given
by 'first_hop'.

>	It seems so obvious to me that a hierarchically structured
>address space in Ethernet (read 802.x) 48 bit addresses would be a
>great improvement over the current kludged 48 bit flat vendor-assigned
>address space coupled with the 32 bit IP address space that I wonder
>why the issue never comes up.  I know all the obvious problems with
>structured Ethernet addresses, but everytime I look at the issue it
>seems to me that structured Ethernet/IP (read 802.x) addresses would
>be a great improvement over flat address space.

I think it would be a bad idea to give up the 48 bits of addressing.
48 bits is more than we'll ever need, right? Fine, then let's keep it
that big. *Maybe* we'll really never need it bigger (yes, I can't
remember if 2^48 is greater than the estimated number of particles in
the Universe...if it is, that's even better). So let's not take any of
the current 48 bits to form the hierarchical address.

The only reason that I think you'd really want to have hierarchical
ethernet addresses is if you want to use them as your IP level
'logical' addresses, but if you do that then you open up lots of
problems: the addresses must be variable length if you want to support
more media than just those that use ethernet-style addresses, which is
really nasty from an implementation point of view (like ISO, which in
general is really nasty from an implementation point of view); and you
end up with volatile addresses wired into IP-level addresses which
have a (presumably) long lifetime - when your ethernet interface goes
to bit heaven, you don't want your computer's IP address to change.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 06:44:22 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP (was Re: Dumb vs. smart host routing)


Bill,

I hate to do this, but I don't like proxy ARP at all.

There are two reasons for why:

First, there are too many network media that don't use ARP for my
taste. ARPANET, X.25, ProNET-10. Maybe FDDI won't? I look at what you
said about these media this way: you're going to have to support
default gateways on them. You want the vendor to support it. The
vendor's IP layer should probably be pretty media-independent, so if
you've got default routers working in the software when you hook up a
system to the ARPANET, you've basically got what you need for ethernet
too. So it's not really an extra work to support it for networks other
than the non-ARP media.

Second, I had a really bad experience with an ethernet at MIT that had
a proxy ARP router on it a few years ago. Dave Bridgham was setting up
a second IP subnet on an ethernet at LCS. But a strange thing was
happening - his packets were disappearing. The proxy ARP router was
sending out ARP replies few milliseconds after the host Dave was
trying to talk to and it ended up gobbling up all the packets. It took
us a long time to track down the problem.

I think there are situations where you might want to set up a second,
test IP subnet or network on an network cable which already has a
different IP subnet or network on it, and that proxy ARP routers which
might believe they're doing exactly the right thing would make it
impossible to do this.

So proxy ARP is unacceptable to me.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 May 88 17:34:44 -0400
From:      Craig Partridge <craig@SH.CS.NET>
To:        geoff@fernwood.mpk.ca.us
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Mail Order TCP-IP.

> What with three books available or soon to be on TCP-IP, take note in the latest
> Black Box Catalog...

Geoff,

    Does the catalog offer Vint Cerf decoder rings?  I've been searching
for one for some time now.... :-)

Craig
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      16-MAY-1988 19:32:32 GMT
From:      CDBP01%VAXD.STRATHCLYDE.AC.UK@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Toothpaste, but also *disinfectant*!
TCP in Britain is actually the name for a brand of disinfectant!

(Tri-Chloro Phenol is reputedly the company's excuse for using these initials)

Competition time: how many uses for liquid TCP could be found for Real TCP?

Answers on a line to:
Alan Fleming
Strathclyde University
Glasgow, Scotland.

CDBP01%VAXD.STRATHCLYDE.AC.UK@CUNYVM.CUNY.EDU (I Think!)
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 18:49:00 EST
From:      <enger@bluto.scc.com>
To:        "craig" <craig@sh.cs.net>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   Decoder Rings
Craig:
	What the community really needs is a good Mills decoder ring!

Bob

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 May 88  22:00:28 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA, "Campus-Size LAN Discussion Group" <BIG-LAN@SUVM>
Subject:   Packet size distribution
Does anyone have any data on the distribution of packet sizes on an
Ethernet?
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 18:50:04 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Timewarp alert

Folks,

At about 2000 UT Saturday the NCAR primary NTP time server took a hit, with
result that until about 1800 UT Sunday the year read 99, not 88. At about
0100 UT Saturday the UDel primary NTP time server also took a hit and
chimed similar nonsense until fixed about an hour later. In all the NTP
primary servers the year is determined (from a file) at boot time and can
be changed subsequently only by an operator command. The year information
is not part of the timecodes broadcast by NBS. In fact, I can find no
evidence of TCP login near the time of warp in either case and have
no reason to suspect operations staff at either location of any mischief.
I therefore tentatively have classified the warps as zoo events and have
alerted the hacker trackers.

Those brave enough to be chiming NTP with one or more of the five NTP
primary time servers should read Appendix D of the document found
in the ~ftp/pub/ntp.doc file in the anonymous login at louie.udel.edu.
This appendix suggests that secondary NTP time servers should peer with
two of the five primary servers along with another secondary server known
to peer with two different primary servers. The voting algorithm used
by the Fuzzball and Unix daemons is designed to cast out falsetickers
most effectively in such configurations.

Dave

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 21:34:44 GMT
From:      craig@SH.CS.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Mail Order TCP-IP.


> What with three books available or soon to be on TCP-IP, take note in the latest
> Black Box Catalog...

Geoff,

    Does the catalog offer Vint Cerf decoder rings?  I've been searching
for one for some time now.... :-)

Craig

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 22:24:18 GMT
From:      roode@orc.olivetti.COM (David Roode)
To:        comp.protocols.tcp-ip
Subject:   network cost recovery

There are benefits of usage insensitive cost recovery as applied to
networking, through the need for universal connectivity and the common
immeasurable benefit derived therefrom.  This is much as it has
traditionally been recognized in not basing service fees on
incremental cost to provide service for such applications as mailing a
letter or installing a new telephone line (for a rural location vs. a
metrapolitan area).

The recent analogy of garbage dumpster capacity being used as a gauge
for waste removal charges was interesting.  So was the observation
that sewage charging is often based on another available metric--fresh
water consumption.  In these cases society has a vested interest in
making the billing not directly usage sensitive.  Who would want his
neighbors piling up sewage or garbage rather than disposing of it?  In
the case of garbage removal, it is probably more common for there to
be a fixed fee per household rather than to let the act of renting a
dumpster invoke a higher fee for the removal.  This makes the charge
less usage-based still.  Nonetheless, all costs are recovered.

I don't like the loading of network service fees on top of actual
costs of a leased line to effect the feeder connection.  It treats as
negligible cases of particular 9600 baud circuits passing more data
than some 56Kb circuits.  Why deny light-usage sites rapid throughput
for that usage?  Aside from very crude load leveling, it seems
needless.

I submit that innovative funding sources could remove the argument
that fully usage sensitive charging is needed at any level.  At the
same time, the main difficulty I see in usage sensitive charging is an
extremely painful transition, for all the reasons that have been
cited.  We could get there, but the casualties and setbacks along the
way would be inevitable.  Certain non-usage based charging would
evolve anyway, so why not consider an alternative?  My claim is that
there is a way to scale the charging schemes of the past to match
the popularity of networks of the present.  Such a step is much less
drastic and offers advantages as well as a smoother transition.

I agree with Craig Partridge's idea of charging only at the feeder
connection and not worrying about exactly what passes through that
connection and where it is going.  The cost of doing detailed
accounting is considerable, so if we avoid this we have just obtained
one subsidy to network usage.  On the other hand, accounting only on
raw usage of a site's feeder connection need not be onerous and offers
benefits over charging based solely on the existence of the feeder
connection.  I feel that network charging should not be based only on
feeder circuit size (and maybe not that at all, beyond passing on the
raw costs of providing the feeder circuit itself). Instead consider
the community to be served by that circuit, including its size and its
nature, and the general level of usage of the circuit.  This could be
quite managable, and I will propose some necessary elements of a
workable realization of this alternative to all-out bean counting:

    (1) Educational and non-profit sites should get discounts, government
    should pay a little more, and others (e.g.  commercial) should pay the
    most of all for a given service.  (2) Smaller communities (all kinds)
    should get discounts to encourage their participation.  (3) Increasing
    the participation by commercial research organizations which pay their
    own freight and then some will significantly add to the subsidy of
    research networking infrastructure currently paid only by the
    government.  This subsidy is not workable if attempted on a
    usage-sensitive basis, i.e. the subsidy has to be a flat one.
    
    (4) Within a category, a year's fees should be set in advance based on
    the previous year's usage.  This provides administrative convenience
    for all concerned.  (5) Organizations which offer identifiable service
    to the community at large should be assessed based on an appropriately
    discounted usage level.  (6) An estimate would be used for the first
    year of an organization's connection. (7) No bill backs would be used
    for deviations over the period of the fee year.  This sort of volume
    pricing has ample precedent in volume purchase agreements commonly in
    use.  (8) Organizations which can not afford the new year's rates
    should be given the ability to invoke a throttle, by downgrading link
    size or limiting throughput.  The limits should be settable across a
    smooth set of incremental values.  (9) In general, organizations will be
    encouraged to find a means to distribute costs, especially since these
    will approximate benefit to the organization in that they are based 
    loosely on volume.  Furthermore, they will be proportional to the
    organization's ability to pay.  They will be designed so as to
    encourage payment out of research overhead, which fully usage-sensitive
    charges are not, and the cost will be known in advance and will be
    controllable.
    
This scheme can be used by any network that chooses to adopt it.
Interconnections between networks, except in special cases like
the NSFNET backbone, provide mutual benefit to both networks,
and no charges need be levied. Each network pays part of the costs.

A fellow in Australia mentioned increased equity if usage-sensitive
charges were employed in the U.S. since it already is in the case of
the Australia-UUNET link.  It's important to note that UUNET is merely
an interface service to the vast UUCP network, which itself has no
central services or central charging scheme of any sort, usage
sensitive or not.  It's this which causes the inequity where Australia
pays all the costs of the UUNET link.  UUNET has no way to assess
charges on all the USENET users who use the link, and aside from
direct UUNET participants also has no way to recover network overhead
costs.  UUCP is a different sort of network backbone than the type of
which we speak in the TCP-IP discussion.  Furthermore the Australia
and other international UUCP network connections are special cases
insofar as even UUCP is concerned.

I could envision support for that link from the network
administrations of the many U.S.  networks other than the UUCP
network, all of which are TCP-IP based except for BITNET.  I am sure
all value mail connectivity with Australia and other nations.  There
is a Federation of these networks which would be the right place to
bring up the issue.  However, only the costs of the international X.25
connection and not the cost of that part which occurs within a nation
should be borne mutually. The part of the path within a given nation
is reciprocated by that part within the destination nation.  I.e.,
when Australia exchanges mail with the U.S. it is currently not billed
for use of a significant distribution network.  The U.S. distribution
net is used for all messages between the two countries, originating in
either.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      15 May 88 23:49:00 GMT
From:      enger@bluto.scc.COM
To:        comp.protocols.tcp-ip
Subject:   Decoder Rings

Craig:
	What the community really needs is a good Mills decoder ring!

Bob

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      16 May 1988 05:13-EDT
From:      CERF@A.ISI.EDU
To:        Mills@LOUIE.UDEL.EDU
Cc:        stjohns@BEAST.DDN.MIL, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  controlling IP "type of service"
Dave,

I forgot about TTL - in that case, how do you explain such long-delayed
packets that arrive well in excess of TTL? Did they take paths that didn't
examine TTL (e.g. hosts offering unauthorized gateway services?).

Vint
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 02:00:28 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Packet size distribution

Does anyone have any data on the distribution of packet sizes on an
Ethernet?

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 02:26:24 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Mail Order TCP-IP.

Craig,

I think you mean Cerfboards, not decoder rings. These can be used to escape
alligators in the swamps, entangle sausage nets and even fry fuzzballs. Vint
can tell you TCP is a mouthwash sold in Britain and what cooks in a bakeoff.
Nevertheless, I don't think any of the older buzzards in the Internet coop
ever thought you could buy TCP-IP with a credit card, much less a Cerfboard.
Lest we forget Premier Buzzard Bob Kahn, you should know there is a pawnshop
in Wellington, New Zealand called the Kahn Store, where you just might find
a better bargain.

Dave

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 02:43:04 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Decoder Rings

Bob,

The decoder ring is next to the Rosetta Stone, which is on your left as you 
enter the British Museum. It resembles a Moebius strip with Linear-B on one
side and ALGOL-68 on the other. Allegedly, it was found in an ancient burial
mound near Ur along with pieces of Cerfboard and embedded in Millstone.
You have to talk like this if you want to become an Internet Buzzard.

Dave

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 05:03:26 GMT
From:      edm@nwnexus.WA.COM (Ed Morin)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: Plenum-Rated Ethernet Transceivers

I was recently faced with the same problem while installing a network in
a building that uses the air space above the ceiling for the cold air
return of the air-conditioning system.  Since we were ordering Cabletron
transceivers, I knew that everything would be ok.  However, once we re-
ceived the transceivers they had little stickers on them saying (I don't
have one with me at the moment) that they could *not* be used in
"pleums"!  So, I contacted Cabletron.  Normally I get terrific service
and attention from them, but this fiasco went on for *weeks* trying to
reconcile this apparent inconsistency.  Nobody seemed to know anything
about the meaning of their NEC 725 (?) specification vs. this crazy
sticker with an apparent misspelling.

It turns out that the transceivers can be put into "air handling *spaces*"
(like ceilings), but *not* in actual ducting (i.e. main air supplies, etc.).
I guess Cabletron is drawing a distinction between an "air handling" spaces
and "plenums"...

Ed Morin
Northwest Nexus Inc.
edm@wa.com

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 May 88 09:37:24 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        "Jeffrey I. Schiller" <jis@BITSY.MIT.EDU>
Cc:        jqj@HOGG.CC.UOREGON.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Dumb vs. smart host routing


>    However you do bring up a problem with single threaded
>machines. What if we modify your scheme so that all routers on a
>network speak some (as yet undefined) protocol to elect one of them
>the "advertised default router" and only this router would respond to
>the "Who can route" message. If this router went down the other
>routers would know and elect a new default router. "Note I have
>simplified the question from "Who can route to network X?" to just a
>simple request for a default router. That router can then send
>redirects later when packets arrive."

The basic idea is good, unfortunately, I need to deal in the real
world (SHUDDER) where a certain well known computer company has made
a network package for PC's and PS/2's that does not understand ICMP
redirect. In fact, the only ICMP that this package supports is Address
Mask Query.

Cheers
Frank Kastenholz
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 May 88 11:32 EST
From:      <LANGFORD%VCUVAX.BITNET@CUNYVM.CUNY.EDU> (Bob Langford)
To:        tcp-ip@sri-nic.arpa
Subject:   How many levels should a domain-style name have?
Hi, I've got a question about domain naming schemes.

We're hooking up a university-wide network using IP/TCP, which will
soon be connected to SURAnet/NSFnet.  Naturally, we want to set up some
domain-style names for our systems, but we're having some disagreements
about how many levels the names should have, i.e., RUBY.VCU.EDU vs
RUBY.MCV.VCU.EDU (no one thinks we need 5 levels!)  We will have about
10 "large" hosts (>10 users), about 5-10 small hosts (1-2 user Suns)
and dozens of Macintoshes or PCs connected on subnets.  Many people here
want 3 level names for ease of remembering, others want 4 level names for
distributed naming (node addresses will be assigned by distributed means,
not a central authority).  Some months ago, someone suggested assigning
nodes 4 level names, but also providing a 3 level "alias" for the most
popular systems.  Is this wise and/or feasible?  What do most places do?

(Extra info:  most of our computers are Pyramids using UNIX, with a few
Sun 3/xxx systems, and a VAX/VMS system running Wollongong software.)

      Bob Langford
      MCV Academic Computing
      Virginia Commonwealth University
      (804) 786-9843
      Bitnet:  LANGFORD @ VCUVAX
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 09:13:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Dave,

I forgot about TTL - in that case, how do you explain such long-delayed
packets that arrive well in excess of TTL? Did they take paths that didn't
examine TTL (e.g. hosts offering unauthorized gateway services?).

Vint

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 10:48:47 GMT
From:      mo@maximo.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   toothpaste


It was somewhere in Europe, Copenhagen, I think, that I 
saw a tube of something named  "TCP" in a shop window.
It turned out to be toothpaste.  I regret not having
bought some.
	-Mike

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 13:37:24 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing



>    However you do bring up a problem with single threaded
>machines. What if we modify your scheme so that all routers on a
>network speak some (as yet undefined) protocol to elect one of them
>the "advertised default router" and only this router would respond to
>the "Who can route" message. If this router went down the other
>routers would know and elect a new default router. "Note I have
>simplified the question from "Who can route to network X?" to just a
>simple request for a default router. That router can then send
>redirects later when packets arrive."

The basic idea is good, unfortunately, I need to deal in the real
world (SHUDDER) where a certain well known computer company has made
a network package for PC's and PS/2's that does not understand ICMP
redirect. In fact, the only ICMP that this package supports is Address
Mask Query.

Cheers
Frank Kastenholz

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 14:23:03 GMT
From:      nmsg@newcastle.ac.uk (Newcastle Micro Support Group)
To:        comp.protocols.tcp-ip
Subject:   Request for Tektronix 4014 TELNET  (Repost)


  Does anyone have knowledge of a Tektronix 4014 version of TELNET ?
  I have a PC with a 3com card in it and a version of KA9Q, which
  gives me tty access to various hosts.  I would like to use some
  graphics.  Any thoughts...

  Additionally I would like to be able to call out and use SSMP
  (Simple Screen Management Protocol) programs on the remote
  hosts, and this involves an SSMP version of TELNET.
  I think I'll probably have to do some programming.  Can anyone point me
  in the direction of some really straightforward programming interfaces
  into TCP/IP code?

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 14:29:50 GMT
From:      ehrlich@blitz (Dan Ehrlich)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Competition for Bridge

In article <599@riddle.UUCP> andrew@riddle.UUCP (Andrew Beattie) writes:
>Does anyone other than Bridge make Ethernet TCP/IP Terminal servers?
>

Let's see now:

	1) Encore Computer - Annex Terminal Server
	2) CISCO

We have all three, Bridge, Encore, CISCO, here at Penn State.  I have had
experience only with Bridge and Encore.  Of the two I would recommend the
Encore over the Bridge any day.

Dan Ehrlich <ehrlich@blitz.cs.psu.edu>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723
Dan Ehrlich <ehrlich@blitz.cs.psu.edu>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 14:44:38 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  controlling IP "type of service"

Vint,

So far as I know, no gateways except fuzzballs take care to calculate
the actual time in queue when decrementing TTL. I of course would
invite corrections to that presumption.

Dave

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 14:55:12 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  toothpaste

Mike,

Thanks for the info. The British TCP claim comes from Jack Haverty
at BBN, Internet Engineer-Buzzard  emeritus.

Dave

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 15:14:29 GMT
From:      wayne@ultra.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: toothpaste and other TCPs

It wasn't that long ago that some major US oil company was screaming
the wonders of adding TCP to its gasoline (was that what gave Shell
gas its extra mileage?), although this particular TCP has been a
well-known gasoline additive for years (spelled phonetically as
something like "tri-creasel-phosphate").  Wonder what it would do for
the mileage of a motor-driven Cerfboard?

      Wayne Hathaway                  ultra!wayne@Ames.ARPA
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 wayne@Ultra.COM
      408-922-0100

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 15:48:29 GMT
From:      dab@oliver.CRAY.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

Bill Westfield of cisco Systems while talking about "Proxy ARP" writes:

> Of course, this only works with hosts on networks where ARP is used for
> address resolution (broadcasts are possible).  But if a host has only a
> point-to-point link to the network, it might as well use whatever gateway
> is at the other end of that link as its default gateway.  This leaves only
> networks like X.25 and the ARPANet (non-broadcast, but not really point-to-
> point either), and it might not be such a bad idea to have those hosts know
> about routing, at least to the extent of having multiple default gateways.

There's more.  For instance, the A series of HYPERchannel adaptors does not
support broadcast, and is not point-to-point.

As far as I know, "Proxy ARP" only works with subnets, for nodes that
don't know about subnets.   In order to send out the ARP request, the
host has to already belive that he can get to the remote host in one
hop.  If my machine is on net 128.62, and I want to get to a machine on
net 128.63, I don't send out an ARP request for the machine on net 128.63.
I have to have a route to 128.63 which points to a machine on net 128.62,
and then I'll be ARPing for the machine on 128.62 which is the next hop to
128.63.

"Proxy ARP" is a wonderful fix in the real world to keep your subnetted
network running when you have hosts that don't know about subnets.  I
don't think that it should be used for anything else, or promoted as a
standard.

			-Dave Borman
			CRAY Research, Inc.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 16:32:00 GMT
From:      LANGFORD@VCUVAX.BITNET (Bob Langford)
To:        comp.protocols.tcp-ip
Subject:   How many levels should a domain-style name have?

Hi, I've got a question about domain naming schemes.

We're hooking up a university-wide network using IP/TCP, which will
soon be connected to SURAnet/NSFnet.  Naturally, we want to set up some
domain-style names for our systems, but we're having some disagreements
about how many levels the names should have, i.e., RUBY.VCU.EDU vs
RUBY.MCV.VCU.EDU (no one thinks we need 5 levels!)  We will have about
10 "large" hosts (>10 users), about 5-10 small hosts (1-2 user Suns)
and dozens of Macintoshes or PCs connected on subnets.  Many people here
want 3 level names for ease of remembering, others want 4 level names for
distributed naming (node addresses will be assigned by distributed means,
not a central authority).  Some months ago, someone suggested assigning
nodes 4 level names, but also providing a 3 level "alias" for the most
popular systems.  Is this wise and/or feasible?  What do most places do?

(Extra info:  most of our computers are Pyramids using UNIX, with a few
Sun 3/xxx systems, and a VAX/VMS system running Wollongong software.)

      Bob Langford
      MCV Academic Computing
      Virginia Commonwealth University
      (804) 786-9843
      Bitnet:  LANGFORD @ VCUVAX

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 17:55:57 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   hosts and gateways and protocols

This is a very nice and timely discussion for me, given where I am
in some product development cycle.

What my tendancy has been is to allow for the specification of a default
router (yes, just one).  If the router isn't specified, then we listen
for RIP broadcasts.  Now, I never know what is INSIDE a RIP packet.  However,
I choose a default router based on the largest RIP packet seen, and I stay
with that router for five minutes or so.  So, if I continue getting RIP
packets, then I keep following routers.

Whenever I receive a host or network ICMP redirect, I update my *HOST* route
(based on the destination IP address which comes along with the ICMP packet).
This host route lives for five minutes or so (maybe 20 minutes).  It then
times out, and we use the current default router to send to (the router
may then send back a redirect, which we will believe).

I am very sympathetic to almost all sides of this debate.  I strongly believe
that hosts should stay out of the routing game.  I strongly *wish* all
hosts had only one interface, but that isn't always desireable.

I also feel for those souls whose routers occasionally crash, and who would
like routes to switch automatically.  I don't believe that just because
you need this capability once per day that should exclude it from being
automated.

Right now, listening for RIP packets is, in many environments, the best way
to locate potential gateways.  There is no reason this needs to have a
separate process listening - consider these packets to be like ICMP packets.

As a design issue, I think that the ISO scheme seems very well thought out.
I want to be able to hear "I'm a router and I'm alive" packets at a fairly
high rate (at least once per minute).

I tend to lean towards unsolicited broadcasts (multicasts, whatever) from the
routers rather than a "query-response" scheme ("any routers out there?" "here
I am") for a few reasons.  First off, there are many more hosts than gateways,
so the unsolicited broadcasts should generate less (broadcast or multicast)
traffic.  Second, I'd rather not have to worry about how a uni-directional
UDP stream is supposed to decide that its packets aren't making it to the
other end of the wire.  Third, I'm not sure that every time TCP retransmits
a packet I want to have to revalidate the route.

Greg Minshall

Kinetics, Inc.		415-947-0998		ucbvax!mtxinu!kinetics!minshall

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 18:40:01 GMT
From:      retrac@RICE.EDU (John Carter)
To:        comp.protocols.tcp-ip
Subject:   Re:  Packet size distribution

Roger,

    When I ran a series of traces of our ethernet (which my or may not
be particularly representative), I found that most packets were either
very small (e.g. ARP, RIP, telnet packets) or very large (e.g. FTP).
Small packets were the most common.  Large packets tended to come in
bursts (such as when a user loads a file in to a workstation).  Medium
sized packets were fairly uncommon.

    There is a paper entitled "Network Measurement of the VMTP
Request-Response Protocol in the V Distributed System" by Cheriton
and Williamson in 1987 ACM Sigmetrics Conference on Measurement and
Modeling of Computer Systems.  They found that there was a similar
distribution for VMTP packets.

John Carter
Rice University
retrac@rice.edu

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 19:03:24 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP

In article <1080@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes:
> I see only one easy answer to the gratuitous compatibility problems
> imposed by 802.3: IGNORE IT!  ...

Yes, but...some vendors are already supporting it.  I'm told by some of
our customers that Gould/SEL machines can do either 'Ethernet 1 or
802.3' (meaning either lengths or types), depending on boot-time
configuration, and cannot send even raw ethernet packets of one kind
when configured for the other.  I've heard more distressing claims
about WIN/TCP for HP-3000's.  This may not be true about either (it's
only our customers beating up on us, demanding interoperability), but it
will no doubt eventually be true of some machines.

It's likely we, at SGI, can figure out how to make our drivers hear
either the old form or RFC-1042.  What should we do for output?
    -Add an option to ifconfig which tells the driver to speak RFC-1042?
    -A per-driver, system configuration option?
    -Some kind of hack for ARP like that for trailers?  Send both kinds 
	of ARP request and guess out what each destination wants by what
	you get back?  But that makes the MTU for the link kind of variable.
	It might be confusing when two such machines talk to each
	other--depending on timing, they might get different conclusions
	about each other.  What about proxy-ARP?

It might be nice if the 4.3bsd compatible vendors could be consistent.

If the problem has been solved, please forgive me, and tell me the
solution.

Vernon Schryver
Silicon Graphics
vjs@sgi.com   or   {pyramid,decwrl,research,allegra,adobe,sun}!sgi!vjs

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 19:32:32 GMT
From:      CDBP01@VAXD.STRATHCLYDE.AC.UK
To:        comp.protocols.tcp-ip
Subject:   Toothpaste, but also *disinfectant*!

TCP in Britain is actually the name for a brand of disinfectant!

(Tri-Chloro Phenol is reputedly the company's excuse for using these initials)

Competition time: how many uses for liquid TCP could be found for Real TCP?

Answers on a line to:
Alan Fleming
Strathclyde University
Glasgow, Scotland.

CDBP01%VAXD.STRATHCLYDE.AC.UK@CUNYVM.CUNY.EDU (I Think!)

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 19:51:16 GMT
From:      merlin@hqda-ai.ARPA (David S. Hayes)
To:        comp.protocols.tcp-ip
Subject:   What is Batch FTP?


     I recently saw an article in "comp.sources.wanted" that made
passing reference to a Batch FTP program.

     I have never heard of Batch FTP.  Can anyone enlighten me?
Thanks,

-- 
David S. Hayes, The Merlin of Avalon	PhoneNet:  (202) 694-6900
UUCP:  *!uunet!cos!hqda-ai!merlin	ARPA:  merlin@hqda-ai.arpa

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 20:38:24 GMT
From:      PETERS@nssdca.GSFC.NASA.GOV (Dave.Peters@SRI-NIC.ARPA, NASA/GSFC/NSSDC)
To:        comp.protocols.tcp-ip
Subject:   TCP in the UK

I recently returned from a year in the United Kingdom where quite often
I would notice large signs saying "TCP AOK".  Rather than attempting to
sell new implementations of TCP/IP for your favourite BBC micro, the
adverts were for a topological disinfectant of some sort.  I wonder if
the active ingredient was that same TCP petrol additive...

Dave Peters

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 23:20:26 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: toothpaste

The stuff I have a sample of is a topical anesthetic, for burns, cuts,
etc.  I'm not sure I'd want to brush my teeth with it -- the label says
it contains phenol and iodine.

What I *really* like is the picture I have of a British advertising poster 
for it.  It says, in large, friendly letters,

	No Need for XYZ,
	Just TCP!
       
Take THAT, CCITT!! :-)

Phil

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      16 May 88 23:47:15 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Decoder Rings


Not quite -- in Dave's case, a ring will only do
if it tells time.  How 'bout a decoder watch?

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 01:41:48 GMT
From:      mark@comp.vuw.ac.nz (Mark Davies)
To:        comp.protocols.tcp-ip
Subject:   Re:  Mail Order TCP-IP.

In article <8805152226.aa12175@Huey.UDEL.EDU> Mills@UDEL.EDU writes:
>Lest we forget Premier Buzzard Bob Kahn, you should know there is a pawnshop
>in Wellington, New Zealand called the Kahn Store, where you just might find
>a better bargain.

I've lived in Wellington for the last 20 years and hadn't heard of this
store.  Just checked the phone book and discovered that it did exist, but
Kahns the pawnshop (actually a TV repairman) has closed down (It is now an
Antique shop).  You will have to try somewhere else.  Of course they may
always have an NCP implementation---but you know how expensive Antique
shops are!  ;-)

mark
-- 
Domainised:  mark@comp.vuw.ac.nz	Bang form: ...!uunet!vuwcomp!mark

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 May 88 09:13:49 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Dumb vs. smart host routing
    <from kasten@mitvma.mit.edu>
     a certain well known computer company has made a network package for PC's
     and PS/2's that does not understand ICMP redirect. 

This is an interesting turn.  What if they try to send to a gateway that does
not forward packets which needed redirect.
 a. host sends to gw A
 b. gw A redirects host to gw B
 c. gw A now has no more buffers, drops pkt
 d. host ignores redirect
 e. go to a

The IP spec does imply some effort be made to forward a redirected packet, but
I interpret the priority to be higher to get the redirect to the host, and
only secondary that the packet be forwarded.

Mike Brescia,
BBNCC gateway group
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 03:08:04 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   "topological disinfectant"

... is clearly something that maintainers of routing protocols need to
have handy at all times...

jbvb

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 04:44:43 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  Proxy ARP (was Re: Dumb vs. smart host routing)


	I think there are situations where you might want to set up a second,
	test IP subnet or network on an network cable which already has a
	different IP subnet or network on it, and that proxy ARP routers which
	might believe they're doing exactly the right thing would make it
	impossible to do this.
	
	So proxy ARP is unacceptable to me.

But you should be able to configure a router to not know about a
network, and therefore not answer requests about it (to `unknow'
the network, as it were).  If you can't do this, it reflects a
flaw in the implementation, not the protocol.

-Philip

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 04:55:05 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: Davidson's book vs. Comer's book

>>is why I turned to Comer's book. Comer's book is MUCH better although some
>>of the chapters (specifically those dealing with routing) didn't feel right.
>>This is probably my fault and I intend to reread the whole book a second time.
 
>No, I felt the same way.  The chapter on routing is too brief and left
>me wanting more.  We need still one more book that tackles some of the
>issues Comer left too briefly treated.  Maybe it's too soon.  For now,
>it's back to the RFCs and IDEAs.

I enjoyed Doug's book also, and thought the "Hints to Implementors"
was a great idea (there should be a 10 Most Deadly Sins RFC [like don't
forward MAC broadcast packets, for instance]).  The routing was a little
thin, however.  A novice might not really see the significance of the
extra-hop problem, and the EGP description was too short.  And even
though EGP-3 is still a moving target, a separate chapter about that
(maybe talking about LANDMARK and Dissimilar Gateway Protocol) would
be good.  To be sure, though, it was an very good book.

-Philip

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 08:55:45 EDT
From:      Nicholas Simicich <NJS@ibm.com>
To:        mcc@etn-wlv.eaton.com, tcp-ip@sri-nic.arpa
Subject:   Re:  Dumb vs. smart host routing

> From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
>
> Binding connections to routes is not necessarily bad.  Binding connections
> to routes will probably be a necessity if, and when, multi-level security
> is implemented.  Not all gateways, hosts, etc. may be accredited to service
> a transmission at a given security level.  Which we lead to some requirement
> for a node to be able to request of each node in a path "can you provide me
> this class (type) of service at this security level?"
>
> Merton

Sure, I'll handle your secure traffic.  Sure, I'll encrypt it for you.

I think that the originator has to get this information from internal
tables, or a trusted server on a trusted path, at the least.
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 May 88 09:39:39 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        Mike Brescia <brescia@PARK-STREET.BBN.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Dumb vs. smart host routing
>From: Mike Brescia <brescia@PARK-STREET.BBN.COM>
>
>    <from kasten@mitvma.mit.edu>
>     a certain well known computer company has made a network package for PC's
>     and PS/2's that does not understand ICMP redirect.
>
>This is an interesting turn.  What if they try to send to a gateway that does
>not forward packets which needed redirect.
> a. host sends to gw A
> b. gw A redirects host to gw B
> c. gw A now has no more buffers, drops pkt
> d. host ignores redirect
> e. go to a

>The IP spec does imply some effort be made to forward a redirected packet, but
>I interpret the priority to be higher to get the redirect to the host, and
>only secondary that the packet be forwarded.

If this occurs then I imagine that the host will remain mute for all
eternity. I was not able to try anything like this though - we are
just going to tell our customers that "Here is a failure mode that we
(ATEX) can not fix - so if it occurs, ......."

We have aother PC based (using the P.D. MIT PC/IP code) product that
will have "multiple default" gateways, as was discussed on the list
earlier. The transport/application layer will ask IP to try another route
in the event of excessive transmission errors (i.e. no receipt of an ACK)

Cheers
Frank Kastenholz
Atex/EPPS - a Kodak Company
All opinions are mine and in no way belong to Atex/EPPS/Kodak (in fact
they don't even know that I am saying this)
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 06:01:38 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: Third TCP-IP Book?

Quick thought (often the deadliest): why not divide Doug's book into
two volumes (chapters 1-16, and 17-$)?  Then he would not be
constrained by length or cost (more pages == higher cost).  It
seems likely that some people would probably only need one of the
two, anyway.

-Philip

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 May 88 13:02:57 PDT
From:      cire@clash.cisco.com
To:        "Jeffrey I. Schiller" <jis@bitsy.mit.edu>
Cc:        KASTEN@mitvma.mit.edu, jqj@hogg.cc.uoregon.edu, tcp-ip@sri-nic.arpa, cire@clash.cisco.com
Subject:   Re: Dumb vs. smart host routing
>> Date: Sat, 14 May 88 20:47:14 EDT
>> From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
>> To: KASTEN@MITVMA.MIT.EDU
>> Cc: jqj@HOGG.CC.UOREGON.EDU, tcp-ip@SRI-NIC.ARPA
>> Subject:  Re: Dumb vs. smart host routing
>>
>>  ...
>>
>> simplified the question from "Who can route to network X?" to just a
>> simple request for a default router. That router can then send
>> redirects later when packets arrive.]
>> 
>> 			-Jeff

A reasonable idea.  It still requires the hosts involved to implement
some kind of redundancy mechanism if the default router goes down.  But
it would not have to know about routing just that it needs to find a
new default.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 06:07:07 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  Mail Order TCP-IP.

> I think you mean Cerfboards, not decoder rings. These can be used to escape
> alligators in the swamps, entangle sausage nets and even fry fuzzballs. Vint
> can tell you TCP is a mouthwash sold in Britain and what cooks in a bakeoff.

I thought the mouthwash was called "VAX69"?

-Philip

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      17 May 1988 13:35:17 EDT
From:      Edward A. Cain <cain@EDN-UNIX.ARPA>
To:        maximo!mo@uunet.UU.NET (Mike O'Dell)
Cc:        tcp-ip@sri-nic.arpa,
Subject:   Re: toothpaste
Mike,

Please check carefully before using TCP in a tube. The British product is
an ointment for piles, not toothpaste. If it's good for both, it's truly an
end-to-end product. (heh)

The two other TCP products I have, both from England, are the liquid anti-septic
and the throat pastilles (lozenges). "For sore throats suck TCP ..."

Ed Cain


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 11:38:37 GMT
From:      piet@cwi.nl (Piet Beertema)
To:        comp.protocols.tcp-ip
Subject:   Re: toothpaste


	...that I saw a tube of something named  "TCP" in a
	shop window. It turned out to be toothpaste.
TCP sounds like a natural abbreviation
for Tooth Cleaning Paste.

-- 
	Piet Beertema, CWI, Amsterdam
	(piet@cwi.nl)

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 12:07:15 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Decoder Rings

A decoder ring network, perhaps?

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 16:12:00 EDT
From:      <yurcik@nrl-lcp.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        yurcik
Subject:   Washington DC Area ACM-SIGCOMM Meeting 6/17
As a result of the responses from Redskins Fans from all over...


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


                           WASHINGTON DC SIGCOMM
                            

                     Association for Computing Machinery
			  Washington, D.C.  Chapter
			  Special Interest Group on
			     Data  Communications
				   

	        	    NETWORK ROUNDTABLE #2
			 Topic : "NETWORK MANAGEMENT"
		        ==============================

DATE:		Friday, June 17, 1988

TIME:		1:00 p.m. to 5:00 p.m.

PLACE:		Naval Research Laboratory
		Building 222 Auditorium
		Washington D.C. 20375-5000

RESERVATIONS:	RSVP *ONLY* with Ms. Kelly Short 8:00AM-3:30PM, (202) 767-3887
		If Ms. Short is unavailable please call back since she
	        is the only maintainer of the list.	
	
		All attendees must RSVP by June 10th because names must be
		left at the guard posts for entry onto the base.   For 
		security reasons, non-U.S. citizens and foreign nationals
		might not be able to attend if special arrangements are not 
	        made in advance.

	        For additional information, contact Bill Yurcik, 
	        "yurcik@nrl-lcp.arpa" or (202) 767-3903.

DIRECTIONS:     Carpooling advised due to parking limitations.  Located just 
                off Interstate 295 near the Capitol Beltway (I-95) and the 
		Wilson Bridge on the Maryland Shoreline of the Potomac River.  
		Signs off I-295 clearly mark the Laboratory exits from the 
		north and south.  Following is directions to the North Gate
	        of NRL which is the closest gate to Building 222.  

FROM THE SOUTH: Take the Capitol Beltway to Maryland exit 2 (I-295 North) on 
		the Maryland side of the Wilson Bridge.  From I-295 take 
		exit 1 (NRL),  turn right at the first light onto Overlook 
		Avenue and then make a left at the next light onto Chesapeake 
		Street.  Proceed slowly with a 15 mph monitored speed limit.  
		Stop at the outer guard house and identify yourself as 
		attending a meeting at NRL. Continue past 2 more stop signs, 
		stop at the NRL guard post and identify yourself by your 
		RSVP name and ask directions if needed.  Bldg. 222 is directly 
		on your left past the gate but parking may be best available 
		by bearing right and parking along the river.

FROM THE NORTH:	Take the Capitol Beltway to Maryland exit 22B,
		(BW Parkway/I-295 South) and follow I-295 past New York Avenue 
		and Bolling Air Force Base.  Take exit 1 (NRL), proceeeding 
		straight past one light, and turn right at the 2nd light 
		onto Chesapeake Street.  Note that Chesapeake Street has a 
		15 mph monitored speed limit.  Stop at the outer guard house 
		and identify yourself as attending a meeting at NRL. Continue 
		past 2 more stop signs, stop at the NRL guard post to identify 
		yourself by your RSVP name and ask directions if needed.  
		Bldg. 222 is directly on your left past the gate but parking 
		may be best available by bearing right and parking along the 
		river.
 			

		                 DRAFT AGENDA
			

PROGRAM:  	1:00-1:10 Greeting/Introduction	   B. Yurcik/ACM member 
						   E. Gardner/SIGCOMM,Chair

GUEST SPEAKER:	1:10-2:00 Keynote Address	   V. Cerf/Corporation for
VINT CERF       "Network Management"               National Research Initiative/
						   National Chair ACM SIGCOMM 
						  
		2:00-2:20 Break

ROUNDTABLES:	Area facility network architects, managers, and implementors 
		will have an opportunity to share experiences and discuss
	        technology issues in response to prepared questions and open
		questions from the audience.
		
		2:20-3:15 Roundtable - "Network Management and the Internet"
			  (Moderated by Vint Cerf)
			Corporation for Open Systems - Howard Berkowitz
			NSF                          - unnamed
			Proteon			     - unnamed
			SURANET                      - Jack Hahn 
			Vitalink Corp.		     - Tim Lee-Thorpe
			University of Maryland       - Mike Petry

		3:20-5:00 Roundtable - "Network Management and the Campus LAN"
			  (Moderated by Walt Roehr, Executive Telecommunication 
			                            Networks)
		        Cisco Corp.	             - unnamed
			DEC			     - unnamed
			IBM                          - unnamed		
			NASA Goddard                 - J. Pat Gary
			National Bureau of Standards - Craig Hunt
			Naval Research Laboratory    - Mac Mcculloch/Bill Fink

********************************************************************************
------
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 12:38:38 GMT
From:      mcleod@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   End-User Performance Measurements

This year at MITRE, we have a task for the DDN PMO to look at network
performance as seen by an end-user. I an interpreting 'end-user' to be an
application protocol, such as TELNET or FTP, to discount the variability
in application protocol implementations. This task includes finding metrics
(such as response time and throughput) that define end-user performance
(we are starting with ANSI X3.102), building a prototype system to measure
those metrics on top of TCP, and actually doing some measurements and writing
about the experience (what numbers did we get, what lessons about measuring
the network did we learn).

In order to also learn from the community (I don't believe we are the first to
attempt end-user performance measurements) I am interested in collecting
information about other end-use performance measurement tools and experiences.
In particular, I would like to know 1)what metrics were used, 2)how they were
measured, 3)what type of tool is used - a separate application or measurements
within an application layer protocol (like FTP), and 4)any problems or lessons
learned about using the tool, doing end-user measurements, doing the data
analysis, etc.

Please respond to me directly -- mcleod@gateway.mitre.org --
I will summarize to the list, if people are interested.

Thank you.

Sue McLeod
The MITRE Corporation, McLean, Virginia

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 13:10:43 GMT
From:      tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday)
To:        comp.protocols.tcp-ip
Subject:   Re: Competition for Bridge


   Dan,

     Could you give me a name and number for someone at Encore and CISCO to
     talk to about their terminal servers.  Here at The Ohio State Univ. we
     currently have Bridge equipment (and have been relatively pleased with it)
     but I would like to cover all the bases.  Thanks for your time.

                       Tom Easterday
                       Instruction and Research Computer Center
                       The Ohio State University

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 13:13:49 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing


    <from kasten@mitvma.mit.edu>
     a certain well known computer company has made a network package for PC's
     and PS/2's that does not understand ICMP redirect. 

This is an interesting turn.  What if they try to send to a gateway that does
not forward packets which needed redirect.
 a. host sends to gw A
 b. gw A redirects host to gw B
 c. gw A now has no more buffers, drops pkt
 d. host ignores redirect
 e. go to a

The IP spec does imply some effort be made to forward a redirected packet, but
I interpret the priority to be higher to get the redirect to the host, and
only secondary that the packet be forwarded.

Mike Brescia,
BBNCC gateway group

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 13:39:39 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

>From: Mike Brescia <brescia@PARK-STREET.BBN.COM>
>
>    <from kasten@mitvma.mit.edu>
>     a certain well known computer company has made a network package for PC's
>     and PS/2's that does not understand ICMP redirect.
>
>This is an interesting turn.  What if they try to send to a gateway that does
>not forward packets which needed redirect.
> a. host sends to gw A
> b. gw A redirects host to gw B
> c. gw A now has no more buffers, drops pkt
> d. host ignores redirect
> e. go to a
 
>The IP spec does imply some effort be made to forward a redirected packet, but
>I interpret the priority to be higher to get the redirect to the host, and
>only secondary that the packet be forwarded.

If this occurs then I imagine that the host will remain mute for all
eternity. I was not able to try anything like this though - we are
just going to tell our customers that "Here is a failure mode that we
(ATEX) can not fix - so if it occurs, ......."

We have aother PC based (using the P.D. MIT PC/IP code) product that
will have "multiple default" gateways, as was discussed on the list
earlier. The transport/application layer will ask IP to try another route
in the event of excessive transmission errors (i.e. no receipt of an ACK)

Cheers
Frank Kastenholz
Atex/EPPS - a Kodak Company
All opinions are mine and in no way belong to Atex/EPPS/Kodak (in fact
they don't even know that I am saying this)

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 16:25:15 GMT
From:      dab@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Proxy ARP (was Re: Dumb vs. smart host routing)


	Actually, there was one other factor that caused proxy-ARP to lose
in that case.  This was the use of a default route in the other gateway.
It didn't actually know a route to this test subnet I was setting up, it
just thought it did (via its default route).  So after proxy-ARPing the
address I was trying to get to, it forwarded the packet off to the ARPA
gateway (its default route), which forwarded the packet off to some random
core gateway (its default route) which hopefully dropped it before it
became an alligator in Dave Mill's swap.
						David Bridgham

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 16:35:46 GMT
From:      Doug_Nelson@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

> As far as I know, "Proxy ARP" only works with subnets, for nodes that
> don't know about subnets.   In order to send out the ARP request, the
> host has to already belive that he can get to the remote host in one
> hop.  If my machine is on net 128.62, and I want to get to a machine on
> net 128.63, I don't send out an ARP request for the machine on net 128.63.
> I have to have a route to 128.63 which points to a machine on net 128.62,
> and then I'll be ARPing for the machine on 128.62 which is the next hop to
> 128.63.
 
Proxy ARP also works in networks where the gateway(s) aren't using
any routing protocol at all.  We teach many of our systems here
that the default route is to themself, with a metric of zero.
This forces an ARP for most hosts outside the (sub)network, whether
within or outside the full network.
 
It helps that we only have one gateway to the outside world.
 
Doug Nelson, Michigan State University, Computer Lab
den@serv1.cl.msu.edu

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 17:33:12 GMT
From:      BAYNESRT@v880np.NEWPORT
To:        comp.protocols.tcp-ip
Subject:   Subscription request


	I would like to subscribe to TCP-IP		
	My name/address is:

	Robert T. Baynes
	ASECC/TAI

	(401)841-4249

	baynesrt%v880np.decnet@nusc-npt.arpa

	Thanks for your help.

	Bob Baynes
	

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 17:35:17 GMT
From:      cain@EDN-UNIX.ARPA (Edward A. Cain)
To:        comp.protocols.tcp-ip
Subject:   Re: toothpaste

Mike,

Please check carefully before using TCP in a tube. The British product is
an ointment for piles, not toothpaste. If it's good for both, it's truly an
end-to-end product. (heh)

The two other TCP products I have, both from England, are the liquid anti-septic
and the throat pastilles (lozenges). "For sore throats suck TCP ..."

Ed Cain

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 18:10:54 GMT
From:      ogud@CHAKRA.CS.UMD.EDU (Olafur Gudmundsson)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet size distribution


> Does anyone have any data on the distribution of packet sizes on an
> Ethernet? 

I have some that shows that most of the traffic is either verry small 
packets <120 or big >= 1024.  

The packet size is dependant on type of machines, protcols and usage. 
The statistics that have been collected here are for large Ethernet
with over 100 Ethernet devices 90 of which are WS (all have their own
disk). 

If there is intrest I can post the main results.
____________________________________________________________________________
Olafur Gudmundsson  Dept. of Computer Science University of Maryland
ARPA: ogud@brillig.umd.edu
UUCP: {...!}uunet!mimsy!ogud		  Tel: (301)-454-6497 (w)
UPS: College Park MD. 20742               ATT: (301)-595-4154 (h)

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 02:24:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Sources V.3.3 / 68020 TCP Stuff
                           LOOKING FOR TCP SOURCES
         
         Add me to the list PLEASE, of those scraping around for legal
         sources of tcp stuff:  telnet, ftp, sendmail ( smtp ), bootp,
         time, whois, all the other Berk nifties, especially if there
         is an ice_cubes chance we could port them to our Mot Sys 1131
         ( AT&T / Mot(System 1131) Sys V R3.3 for MC68020. 
         
         We are stuck with the CMC ENP card (VME Bus).  Vendor doesn't
         deliver SMTP / sendmail.  We are ATT/MOT Sys V source license
         holder. 

         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------
------
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 02:57:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   *Ethernet* vs *802.3* or whatever ( 1 vs 2 )

         Just got involved with trying to track down interface between
         HP3000 (MPE_V OS) and my DEC-VMS/SUN/SysV compatible hosts. 
         
         The Wollongong folks offered me a possible solution which may
         shed some light on the Common Ethernet ( we most ALL use ) VS
         *IEEE 802.3*. 
         
         I can't distinguish between them in my limited understanding.
         As I come to understand CISCO / cisco offers a bridge which
         takes E_1 from net_1 and translates the E_1 packets into E_2
         packets to resend on net_1, potentially, or on net_2 and vice
         versa. 
         
         From this proposition, I infer the E_1 and E_2 packets (1)
         may coexist on one net but (2) cannot be substituted directly
         for each other. 
         
         Would someone like to further enlighten me?
         
         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------
------
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 20:02:57 GMT
From:      cire@clash.cisco.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

>> Date: Sat, 14 May 88 20:47:14 EDT
>> From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
>> To: KASTEN@MITVMA.MIT.EDU
>> Cc: jqj@HOGG.CC.UOREGON.EDU, tcp-ip@SRI-NIC.ARPA
>> Subject:  Re: Dumb vs. smart host routing
>>
>>  ...
>>
>> simplified the question from "Who can route to network X?" to just a
>> simple request for a default router. That router can then send
>> redirects later when packets arrive.]
>> 
>> 			-Jeff

A reasonable idea.  It still requires the hosts involved to implement
some kind of redundancy mechanism if the default router goes down.  But
it would not have to know about routing just that it needs to find a
new default.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      17 May 88 20:12:00 GMT
From:      yurcik@NRL-LCP.ARPA
To:        comp.protocols.tcp-ip
Subject:   Washington DC Area ACM-SIGCOMM Meeting 6/17

As a result of the responses from Redskins Fans from all over...


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


                           WASHINGTON DC SIGCOMM
                            

                     Association for Computing Machinery
			  Washington, D.C.  Chapter
			  Special Interest Group on
			     Data  Communications
				   

	        	    NETWORK ROUNDTABLE #2
			 Topic : "NETWORK MANAGEMENT"
		        ==============================

DATE:		Friday, June 17, 1988

TIME:		1:00 p.m. to 5:00 p.m.

PLACE:		Naval Research Laboratory
		Building 222 Auditorium
		Washington D.C. 20375-5000

RESERVATIONS:	RSVP *ONLY* with Ms. Kelly Short 8:00AM-3:30PM, (202) 767-3887
		If Ms. Short is unavailable please call back since she
	        is the only maintainer of the list.	
	
		All attendees must RSVP by June 10th because names must be
		left at the guard posts for entry onto the base.   For 
		security reasons, non-U.S. citizens and foreign nationals
		might not be able to attend if special arrangements are not 
	        made in advance.

	        For additional information, contact Bill Yurcik, 
	        "yurcik@nrl-lcp.arpa" or (202) 767-3903.

DIRECTIONS:     Carpooling advised due to parking limitations.  Located just 
                off Interstate 295 near the Capitol Beltway (I-95) and the 
		Wilson Bridge on the Maryland Shoreline of the Potomac River.  
		Signs off I-295 clearly mark the Laboratory exits from the 
		north and south.  Following is directions to the North Gate
	        of NRL which is the closest gate to Building 222.  

FROM THE SOUTH: Take the Capitol Beltway to Maryland exit 2 (I-295 North) on 
		the Maryland side of the Wilson Bridge.  From I-295 take 
		exit 1 (NRL),  turn right at the first light onto Overlook 
		Avenue and then make a left at the next light onto Chesapeake 
		Street.  Proceed slowly with a 15 mph monitored speed limit.  
		Stop at the outer guard house and identify yourself as 
		attending a meeting at NRL. Continue past 2 more stop signs, 
		stop at the NRL guard post and identify yourself by your 
		RSVP name and ask directions if needed.  Bldg. 222 is directly 
		on your left past the gate but parking may be best available 
		by bearing right and parking along the river.

FROM THE NORTH:	Take the Capitol Beltway to Maryland exit 22B,
		(BW Parkway/I-295 South) and follow I-295 past New York Avenue 
		and Bolling Air Force Base.  Take exit 1 (NRL), proceeeding 
		straight past one light, and turn right at the 2nd light 
		onto Chesapeake Street.  Note that Chesapeake Street has a 
		15 mph monitored speed limit.  Stop at the outer guard house 
		and identify yourself as attending a meeting at NRL. Continue 
		past 2 more stop signs, stop at the NRL guard post to identify 
		yourself by your RSVP name and ask directions if needed.  
		Bldg. 222 is directly on your left past the gate but parking 
		may be best available by bearing right and parking along the 
		river.
 			

		                 DRAFT AGENDA
			

PROGRAM:  	1:00-1:10 Greeting/Introduction	   B. Yurcik/ACM member 
						   E. Gardner/SIGCOMM,Chair

GUEST SPEAKER:	1:10-2:00 Keynote Address	   V. Cerf/Corporation for
VINT CERF       "Network Management"               National Research Initiative/
						   National Chair ACM SIGCOMM 
						  
		2:00-2:20 Break

ROUNDTABLES:	Area facility network architects, managers, and implementors 
		will have an opportunity to share experiences and discuss
	        technology issues in response to prepared questions and open
		questions from the audience.
		
		2:20-3:15 Roundtable - "Network Management and the Internet"
			  (Moderated by Vint Cerf)
			Corporation for Open Systems - Howard Berkowitz
			NSF                          - unnamed
			Proteon			     - unnamed
			SURANET                      - Jack Hahn 
			Vitalink Corp.		     - Tim Lee-Thorpe
			University of Maryland       - Mike Petry

		3:20-5:00 Roundtable - "Network Management and the Campus LAN"
			  (Moderated by Walt Roehr, Executive Telecommunication 
			                            Networks)
		        Cisco Corp.	             - unnamed
			DEC			     - unnamed
			IBM                          - unnamed		
			NASA Goddard                 - J. Pat Gary
			National Bureau of Standards - Craig Hunt
			Naval Research Laboratory    - Mac Mcculloch/Bill Fink

********************************************************************************
------

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 00:48:12 GMT
From:      km@emory.uucp (Ken Mandelberg)
To:        comp.periphs,comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Postscript Printers with ethernet interface?

The only Postscript (or clone) laserprinters I know that has
an ethernet tcp/ip interface are by Imagen. Does anyone know
of any others?

(Dec's DECNET printers don't count).
-- 
Ken Mandelberg      |  {decvax,sun!sunatl,gatech}!emory!km  UUCP
Emory University    |  km@emory                             BITNET
Dept of Math and CS |  km@emory.ARPA                        ARPA,CSNET
Atlanta, GA 30322   |  Phone: (404) 727-7963

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 01:15:07 GMT
From:      magreer@grand.waterloo.edu (Mark Greer)
To:        comp.protocols.tcp-ip
Subject:   Compile of Transport protocols



	Hello everyone, I was wondering if I could impose on you for a
few moments?  I'd like to compile a list of all the transport level
protocols that anyone can think of that have some sort of formal
description.  First ones that come to mind are TCP (of course), ISO,
VMTP, RDP, NetBLT ...  What else is there?  Thanks in advance!

						Mark

P.S. Please ***MAIL*** replies directly to me (I'll post a summary),
thanks.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 01:19:06 GMT
From:      magreer@grand.waterloo.edu (Mark Greer)
To:        comp.protocols.tcp-ip
Subject:   Compile of Transport protocols



Oops, I forgot to give my address.  I'll post the message again...

>  	Hello everyone, I was wondering if I could impose on you for a
>  few moments?  I'd like to compile a list of all the transport level
>  protocols that anyone can think of that have some sort of formal
>  description.  First ones that come to mind are TCP (of course), ISO,
>  VMTP, RDP, NetBLT ...  What else is there?  Thanks in advance!
>  
>  						Mark
>  
>  P.S. Please ***MAIL*** replies directly to me (I'll post a summary),
>  thanks.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mark Greer			magreer@grand.waterloo.edu
University of Waterloo		magreer@grand.waterloo.cdn
Waterloo, Ontario		magreer@grand.uwaterloo.ca
Canada				{network backbone}!watmath!grand!magreer

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 01:23:54 GMT
From:      jdp@killer.UUCP (Jim Pritchett)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.sys.dec
Subject:   DECNET vs. tcp-ip?


     Hello,
            I am posting this request for a friend without net.access.  Please
respond by Email since I dont usually frequent all of the newsgroups on this
message.

     Could someone out there please provide me with a list of the relevant
pros and cons of using DECNET vs. tcp-ip?  The current hardware involved is a
VAX 8800 network (DECNET), some MicroVAXen, and (the new part!) several Silicon
Graphics Iris workstations.  Naturally, the SG machines run their version of
Unix, while the DEC machines are running VMS.  Please start with a general
comparison of the two protocols before discussing the specific hardware in
question.  Other, very different hardware may/will be added in the future, so
we would like to have more info.

                      Please respond by Email.
                                                Thanks,
                                                         Jim Pritchett


PS.  Please, no flames about how dumb/impossible it is to use DECNET on a Unix
machine.  We have been told that a third party can make this run for us if we
want it.  (Sorry, but I dont have any more info on this.)  I dont know whether
the Iris really can run DECNET, I am just relaying the request.

                      Again, thank you for your help in this matter.

~.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 May 88 10:20:02 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        Greg Minshall <mtxinu!kinetics!minshall@ucbvax.Berkeley.EDU>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: hosts and gateways and protocols

>What my tendancy has been is to allow for the specification of a default
>router (yes, just one).  If the router isn't specified, then we listen
>for RIP broadcasts.  Now, I never know what is INSIDE a RIP packet.  However,
>I choose a default router based on the largest RIP packet seen, and I stay
>with that router for five minutes or so.  So, if I continue getting RIP
>packets, then I keep following routers.

This assumes that your host can understand that the packet is a RIP
packet. If my routers use another IGP then the hosts will not know that
it is an IGP packet so they can not "backtrack" to the source of the
packet and get a router.


>I also feel for those souls whose routers occasionally crash, and who would
>like routes to switch automatically.  I don't believe that just because
>you need this capability once per day that should exclude it from being
>automated.

Unfortunately I must strongly disagree with the last sentence. TCP/IP is
entering the non-technical world very rapidly. The company that I work
for makes large editorial systems for newspapers - lets reporters and
ad takers enter their material, editors edit it, layout people design and
build the pages and then output the whole thing to a photo typesetter.
Newspaper people (reporters/editors/etc) know next to nothing about
networking and we can't really teach them. This model is valid in more
and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The
recovery mechanism is required for a very simple reason - money. If a
newspaper doesn't go to press because the network broke then the paper
does not realize its advertising revenues - and that is the name of the
game for all of the "commercial" TCP/IP sites.

I think that the idea of using multicasts/broadcasts is better than the
query/response model. It lets the hosts detect a gateway failure
before they go through a few retransmissions wasting resources (assuming that
the hosts are reasonably intelligent). The only possible problem is that
there may be networks with many gateways and the "I am a gateway" traffic
could get to be burdensome (especially for small hosts that can't handle
many packets per second - e.g. PC's). Perhaps using an Ethernet multicast
address (for Ethernet networks) would be the way to go - it could let
small hosts filter out the unwanted traffic. If this is done, though,
a query/response mechanism may also be needed.

Cheers
Frank Kastenholz
EPPS Inc - a Kodak Company
All opinions are mine........
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      18 May 1988 10:42-EDT
From:      GBELING@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   more about TCP
hello, 
here in good old europe you do not only find toothpaste but 
also really hardware:
just in front of me on my desk there is a little box with a power 
connection, a switch and a red lamp which precipitates a little heat:
that is a real internet instrument from the time when Khanyards tried 
to repair cerfbords in order to keep single packet-steamers moving.
this instrument is nothing else than a soldering iron which calls 
itself TCP but to the hell i do not know why. (german manufacturer)
may be darpa should found a museum with little things like this 
so that people at the year 2000 remember what networking is. 
regards gerd beling
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 08:15:19 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing


Why can't a host just ARP for any destination and expect the
appropriate gateway(s) to answer?  If there were a hopcount
field in the ARP record, I think this would solve all the problems.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 May 88 13:21:35 EDT
From:      "Drew M. Powles" <dpowles@ccd.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        dpowles@ccd.bbn.com
Subject:   connecting Internets?
Has any thought been given to the mechanisms and methodologies to be
used for interconnecting separate Internets with overlapping address
spaces?  Granted, there's only one Internet at the moment, and we be
it, but there may come a time where more than one Internet springs up
along side of the existing Internet, even in the DoD, with completely
separate administration mechanisms, including address assignment
(although still based on the internetworking protocols of choice at
the time, whether that's DoD IP, or ISO IP down the road).  And these
side-by-side Internets may have some interoperability requirements.
Can interoperability be successfully implemented at an Internet (or
read Level 3) position in the protocol stack, or do we have to resort
to some application level funniness?  I know this may seem to be a
silly or somewhat naive question, but there are actual situations
where this could eventually arise.  Any thoughts? 

many thanks,

dmp

dpowles@bbn.com
Drew M. Powles
BBN Communications 
9810 Patuxent Woods Drive
Columbia, MD 21046

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 10:24:00 GMT
From:      efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY")
To:        comp.protocols.tcp-ip
Subject:   Sources V.3.3 / 68020 TCP Stuff


                           LOOKING FOR TCP SOURCES
         
         Add me to the list PLEASE, of those scraping around for legal
         sources of tcp stuff:  telnet, ftp, sendmail ( smtp ), bootp,
         time, whois, all the other Berk nifties, especially if there
         is an ice_cubes chance we could port them to our Mot Sys 1131
         ( AT&T / Mot(System 1131) Sys V R3.3 for MC68020. 
         
         We are stuck with the CMC ENP card (VME Bus).  Vendor doesn't
         deliver SMTP / sendmail.  We are ATT/MOT Sys V source license
         holder. 

         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------
------

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 10:57:00 GMT
From:      efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY")
To:        comp.protocols.tcp-ip
Subject:   *Ethernet* vs *802.3* or whatever ( 1 vs 2 )


         Just got involved with trying to track down interface between
         HP3000 (MPE_V OS) and my DEC-VMS/SUN/SysV compatible hosts. 
         
         The Wollongong folks offered me a possible solution which may
         shed some light on the Common Ethernet ( we most ALL use ) VS
         *IEEE 802.3*. 
         
         I can't distinguish between them in my limited understanding.
         As I come to understand CISCO / cisco offers a bridge which
         takes E_1 from net_1 and translates the E_1 packets into E_2
         packets to resend on net_1, potentially, or on net_2 and vice
         versa. 
         
         From this proposition, I infer the E_1 and E_2 packets (1)
         may coexist on one net but (2) cannot be substituted directly
         for each other. 
         
         Would someone like to further enlighten me?
         
         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!nswed5!efb |
         | USNSWSES - Code 4V33   } { ARPA:  efbatey@NOBBS.UCSB.EDU |
         |   After HOSTS.TXT.726  } {        efbatey@NSWSES.ARPA    |
         ------------------------------------------------------------
------

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 13:03:48 GMT
From:      tsmith@USNA.MIL ("Tim G. Smith", Mechanical)
To:        comp.protocols.tcp-ip
Subject:   SendMail

This is a long message. If your aren't interested in sendmail and large
networks then you might as well skip this message. You may have seen
this message elsewhere as it is being cross posted to big-lan,
sun-spots, nfs, tcp-ip, and unix-wizards.  If there is a more
appropriate list to discuss this in let me know and I will take this
matter there.

We here at the US Naval Academy (USNA) in Annapolis, MD are building a
network. We have been operating an ethernet LAN connecting several
minis and workstations for quite some time. We use thin, thick, and
fiber based ethernet. We are reasonably well versed in TCP/IP and have
experience with mpr's and gateways. Our hosts run the gamut from
Zenith PC AT clones using SUNs PCNFS package to SUN workstations to
VAX and Gould minis. 

We have about 20 hosts on our network that are capable of exchanging
mail via sendmail. We are in a growth process and expect our number
of workstations to increase dramatically as our new network is
installed and more folks buy workstations. It is quite possible that
we will eventually have 4-7k workstations and their servers attached
to our network in the future. 

We currently use MMDF as our mail handler but are in the process of
switching to sendmail as sendmail seems to be emerging as the
"standard" mail handler. I have been selected to work on installing
sendmail and planning our mail routing system. I have spent a
reasonable amount of time working with sendmail and thought I would
ask around to see if what everyone else is doing. 

Here is what I am planning/doing....

Some background...

First, USNA will switch from 2 level domains to 3 level. Currently
hostnames are of the form "machine.USNA.MIL", in the near future
hostnames will change to the form "machine.division.USNA.MIL" (if
necessary we might even switch to 4 level domains-
"machine.department.division.USNA.MIL"). There will be an
authoritative host named USNA.MIL. There will also be a host (or
possibly an alias pointing to a host) for each sub-domain, ie there
will be a sub-domain named "math.USNA.MIL" with a primary server named
"math.USNA.MIL". 

Second, every user's home directory will be made available to him on
every workstation in the yard. The goal is to allow any user to sit
down in front of any workstation in the yard and be able to login and
have his files available. Yes, I realize that will involve a tremendous
amount of NFS cross mounts and may not actually be feasible but that
is the plan for the time being. How the password file updates will be
made has not yet been determined. Ideally I would like to use SUN's
Yellow Pages to handle all of the password mess. I am not sure how may
vendors do/will support YP but I will worry about that problem later.

I have come up with the following tenets that I think are wise.  If
you disagree then send me mail and we can discuss it- maybe we all can
learn something new about sendmail. I would prefer that all responses
come straight to me and I will summarize to the net if there is
interest. Maybe there is enough interest to start a sendmail interest
group (provided there isn't already one that I don't know about). 

Sendmail workstation/server configuration philosophy: 
(aka "the gospel according to tim")
-------------------------------------------------------

-All mail should live on a sub-domain host. Individual workstations
should never receive incoming mail- there WILL NOT be a mailer daemon
running on the workstation to receive incoming mail. Whether mail will
live in /usr/spool/mail or the user's home directory is yet to be
decided. I am leaning towards hacking sendmail to put mail in the
user's home directory.

-Workstations punt all mail to their sub-domain server. Workstations
exchange mail only with their sub-domain server. Only outgoing mail is
handled by workstations.

-Workstations should have very minimal configuration files on them.
Workstations should have a sendmail.cf that is virtually identical to
all others in the yard. Workstation sendmail.cf's should essentially
be "maintenance free". 

-The address data in intra-USNA messages will never contain a
workstation hostname- only sub-domain names will be used. (There will
be a host or host alias with the sub-domain name.)

-Inter-sub-domain mail (ie intra-USNA) can be directly routed from one
sub-domain server to another.

-Mail bound for destinations outside USNA will be routed from the
sub-domain host to the USNA.MIL server. This mail will have USNA.MIL
in the address lines. Sub-domain names will never appear in outgoing
message address lines. This will allow USNA.MIL to reliably accept
mail from the outside world regardless of the status of the internal
USNA network.

-Mail arriving at USNA.MIL from outside hosts will be forwarded to the
proper server using a large central data base of aliases on the
USNA.MIL server. Individual users will also be able to forward their
mail via the .forward file in their home directory.

---------- End of Philosophy Statement--------------------


Here is a typical scenario that I imagine...

User "joe" invokes the sending front end to sendmail on his workstation.
He composes and addresses a message to user "mike" and hands it to his
mail agent to pass to sendmail. Sendmail on the local workstation
starts up and the following takes place:

1) The workstation punts the message to the sub-domain server.

2) The sub-domain server tries to deliver the mail. If the
sub-domain-server finds that "mike" is a user who gets his mail on
this server then the mail is delivered as per sendmail's local mail
delivery procedures. If the sub-domain-server finds that "mike" is a
user who gets his mail on another sub-domain-server then the mail is
passed to that server. If the local sub-domain-server cannot determine
where "mike" gets his mail then the message is punted to USNA.MIL (the
next level up the domain ladder).

3) USNA.MIL gets the mail and tries to deliver it. If USNA.MIL
knows who the user is the mail will get delivered- if USNA.MIL
doesn't know who the user is then that user doesn't exist and
an error should be returned to the sender.

What needs to be done to make all this happen is not yet known. 

SUN's Yellow Pages service either complicates or simplifies this whole
issue. Do we expect all the machines in the yard to understand YP (it
would sure be nice if they did!)? I doubt that I can count on all of
the yard understanding YP. I am open to suggestions/opinions, one way
or another.

------------------------------------------------------------
Problems I for see:

-All sorts of "odd" cases...

A user could be logged into a workstation in a division other than his
own sending mail to anyone. 

Not a major problem but something to keep in mind when "Reply-To:" and
"From:" lines are being set up. What should the "Reply-To:" and
"From:" lines say? Should they list the sub-domain server that the
user is sending from?  Should they list the user's "home" sub-domain?
(I would tend think so.)

If the mail is addressed to someone outside of USNA then the problem
will go away since (according to the tenets above) all mail leaving
USNA should have its "Reply-To:"  and "From:"  fields rewritten to the
form "user@USNA.MIL". 

A user may prefer to receive his mail on a machine other than his
"home" sub-domain server. No big deal, a .forward file should handle
this without any problems (I think).

Where do aliases get expanded? I have just about ruled out an alias
expansion on each workstation. I would think that they could be
expanded on either the sub-domain server or on USNA.MIL (or maybe on
both). 

-Conflicts over file locking and simultaneous access to the user's
mailbox.

Here is a possible scenario of locking problems...

User "joe" is reading his mail on workstation "xxx.math.USNA.MIL".
joe's workstation is diskless and mounts its files from his sub-domain
server. In order for this to happen the directory that joe's mailbox
lives in will have to be NFS mounted on his workstation. For joe to be
able to delete messages from his mailbox he will need write
permissions on his mailbox. Thus the NFS mount of the directory
containing joe's mailbox will have to be mode "rw". I see a potential
problem here. If joe is has just finished deleting messages from his
mailbox and is updating it when a new message comes in (ie 
math.USNA.MIL tries to deliver it) there could be an ugly scene as the
process trying to purge the deleted messages from the mailbox and
the delivering agent fight over who gets to write in the mailbox file.

So what happens in the above case? 

-Where do users mailboxes live?

If I already have all sorts of home directories NFS cross-mounted all
over the place I certainly don't want to add to the mess by cross
mounting /usr/spool/mail all over. Not to mention what do I call the
directories? I would be NFS mounting several different /usr/spool/mail
directories from several different servers. I have already ruled out
the idea of a single machine with a massive /usr/spool/mail for
several reasons. Ideally I would like to have each user's mailbox live
in his home directory.

--------------------------------------------------
Sendmail Gripes:

-sendmail.cf cannot find out its domain (or subdomain) internally (at
least I can't figure out a way to do this). This would be a nice
feature to have so we don't have to hard code this info into each
sendmail.cf. (Isn't there a system call that returns the domain name
of a host? How about adding an internal macro to sendmail to add this
feature.)

-It should be possible to configure sendmail to have the user's mailbox
live anywhere (Like maybe their home directory).


Well that is about it. I would like to hear from others- sendmail
experiences, solutions to my problems, ideas about what to do next, or
just commiseration would all be appreciated. 

NOTE: I LIKE SENDMAIL! I think it is very flexible and powerful. I am
simply pointing out my difficulties (and non-difficulties) and asking
whatcha'all think. So please spare me any flames telling me I don't
appreciate sendmail and that I should be condemned to an afterlife in
a post office in hell doing "manual mail routing". OK?

Looking forward to hearing from everybody,
	Tim Smith		
US mail:CADIG mailstop: 11G	E-mail:
	US Naval Academy	internet:tsmith@USNA.MIL
	Annapolis, MD 21402	uucp	:...!uunet!usna!tsmith
MaBell :(301)267-4413
					

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 14:20:02 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: hosts and gateways and protocols


>What my tendancy has been is to allow for the specification of a default
>router (yes, just one).  If the router isn't specified, then we listen
>for RIP broadcasts.  Now, I never know what is INSIDE a RIP packet.  However,
>I choose a default router based on the largest RIP packet seen, and I stay
>with that router for five minutes or so.  So, if I continue getting RIP
>packets, then I keep following routers.

This assumes that your host can understand that the packet is a RIP
packet. If my routers use another IGP then the hosts will not know that
it is an IGP packet so they can not "backtrack" to the source of the
packet and get a router.


>I also feel for those souls whose routers occasionally crash, and who would
>like routes to switch automatically.  I don't believe that just because
>you need this capability once per day that should exclude it from being
>automated.

Unfortunately I must strongly disagree with the last sentence. TCP/IP is
entering the non-technical world very rapidly. The company that I work
for makes large editorial systems for newspapers - lets reporters and
ad takers enter their material, editors edit it, layout people design and
build the pages and then output the whole thing to a photo typesetter.
Newspaper people (reporters/editors/etc) know next to nothing about
networking and we can't really teach them. This model is valid in more
and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The
recovery mechanism is required for a very simple reason - money. If a
newspaper doesn't go to press because the network broke then the paper
does not realize its advertising revenues - and that is the name of the
game for all of the "commercial" TCP/IP sites.

I think that the idea of using multicasts/broadcasts is better than the
query/response model. It lets the hosts detect a gateway failure
before they go through a few retransmissions wasting resources (assuming that
the hosts are reasonably intelligent). The only possible problem is that
there may be networks with many gateways and the "I am a gateway" traffic
could get to be burdensome (especially for small hosts that can't handle
many packets per second - e.g. PC's). Perhaps using an Ethernet multicast
address (for Ethernet networks) would be the way to go - it could let
small hosts filter out the unwanted traffic. If this is done, though,
a query/response mechanism may also be needed.

Cheers
Frank Kastenholz
EPPS Inc - a Kodak Company
All opinions are mine........

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 14:27:56 GMT
From:      nancy@ftp.COM (Nancy Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP in the UK


    I recently returned from a year in the United Kingdom where quite often
    I would notice large signs saying "TCP AOK".  Rather than attempting to
    sell new implementations of TCP/IP for your favourite BBC micro, the
    adverts were for a topological disinfectant of some sort.  I wonder if
    the active ingredient was that same TCP petrol additive...

Actually, I think that's TSP (tri-sodium phosphate)... it's used to
clean floors and walls and such.

	-Nancy Connor
	FTP Software
	nancy@ftp.com

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 14:42:00 GMT
From:      GBELING@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   more about TCP

hello, 
here in good old europe you do not only find toothpaste but 
also really hardware:
just in front of me on my desk there is a little box with a power 
connection, a switch and a red lamp which precipitates a little heat:
that is a real internet instrument from the time when Khanyards tried 
to repair cerfbords in order to keep single packet-steamers moving.
this instrument is nothing else than a soldering iron which calls 
itself TCP but to the hell i do not know why. (german manufacturer)
may be darpa should found a museum with little things like this 
so that people at the year 2000 remember what networking is. 
regards gerd beling

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 17:21:35 GMT
From:      dpowles@CCD.BBN.COM ("Drew M. Powles")
To:        comp.protocols.tcp-ip
Subject:   connecting Internets?

Has any thought been given to the mechanisms and methodologies to be
used for interconnecting separate Internets with overlapping address
spaces?  Granted, there's only one Internet at the moment, and we be
it, but there may come a time where more than one Internet springs up
along side of the existing Internet, even in the DoD, with completely
separate administration mechanisms, including address assignment
(although still based on the internetworking protocols of choice at
the time, whether that's DoD IP, or ISO IP down the road).  And these
side-by-side Internets may have some interoperability requirements.
Can interoperability be successfully implemented at an Internet (or
read Level 3) position in the protocol stack, or do we have to resort
to some application level funniness?  I know this may seem to be a
silly or somewhat naive question, but there are actual situations
where this could eventually arise.  Any thoughts? 

many thanks,

dmp

dpowles@bbn.com
Drew M. Powles
BBN Communications 
9810 Patuxent Woods Drive
Columbia, MD 21046

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 17:38:54 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: hosts and gateways and protocols

In article <8805161802.AA15658@mtxinu.UUCP> minshall@kinetics.UUCP (Greg Minshall) writes:
>Right now, listening for RIP packets is, in many environments, the best way
>to locate potential gateways.  There is no reason this needs to have a
>separate process listening - consider these packets to be like ICMP packets.

Many PC's that are out on the Internet right now aren't on the
Internet full time. They're running TCP on demand - when user wants to
telnet, then they're active on the net and the rest of the time
they're deaf dumb and blind.

>Third, I'm not sure that every time TCP retransmits a packet I want to
>have to revalidate the route.

I don't think TCP should revalidate the route every time it
retransmits. I think it should when it's decided it's in trouble.
Which should be, perhaps, when it's noticed that the round trip delay
has been going up steadily or that it's half of the way to deciding
the connection is dead. These are just suggestions, I don't have any
definite heuristics for it. If I were writing another IP and TCP
implementaiton I'd probably try to put something like this in it and
experiment with it, but I'm not right now, so I'm not really sure
exactly what conditions to do it under.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 17:42:04 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re:  Proxy ARP (was Re: Dumb vs. smart host routing)

In article <8805170444.AA20271@Larry.McRCIM.McGill.EDU> philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) writes:
>But you should be able to configure a router to not know about a
>network, and therefore not answer requests about it (to `unknow'
>the network, as it were).  If you can't do this, it reflects a
>flaw in the implementation, not the protocol.
>
>-Philip


Suppose I don't own and run all the routers. Suppose the university or
corporate telecommunications office does, or suppose BBN runs one of
them, or the company down the street. I don't necessarily have control
over all the computers on my network, and the level of effort needed
to go through to get the necessary changes done to some of them for 15
minutes of testing may be prohibitive.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 18:47:39 GMT
From:      David_J_Buerger@cup.portal.com
To:        comp.periphs,comp.lang.postscript,comp.protocols.tcp-ip
Subject:   Re: Postscript Printers with ethernet interface?


I understand that Talaris has a printer that can act as an
Ethernet node.  They have a PostScript upgrade module for that
printer in beta, which should be released in a few months.  Call
them for more info. at 619/587-0787.

Standard disclaimer...


David Buerger
dbuerger@scu.bitnet

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 19:55:17 GMT
From:      jtn@potomac.ads.com (John T. Nelson)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   Need info on Ethernet products for the IBM AT and Sun


We would like to network our IBM AT to one of our Sun Microsystems
computers.  The ideal method is to just plug the AT into the Sun's
ethernet network using an add--on ethernet interface card.  Someone
recommended the Western Digital Ethercard for this purpose.

But what kind of software is available for the IBM AT that will let me
communicate with Suns?  We would like to do basic things like file
transfer, finger, telnet and maybe hardcopy on the Sun from the AT if
that can be done.

Recommendations?

Would TOPS for the AT provide anything that I need?  TOPS would have
to be run on the Sun I suppose and that's probably expensive.  Are
there hardware interfaces for the AT that will let me communicate with
Appletalk (well there must be since people do connect ATs to
Appletalk)?



-- 



John T. Nelson			UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems	Internet:  jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401		(703) 243-1611

Cherish                Conserve                Consider                Create

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 21:01:23 GMT
From:      guru@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   Re: Davidson's book vs. Comer's book


>>is why I turned to Comer's book. Comer's book is MUCH better although some
>>of the chapters (specifically those dealing with routing) didn't feel rig
>> [Stuff Deleted]
 
    >No, I felt the same way.  The chapter on routing is too brief and left
    [Stuff Deleted]

    I enjoyed Doug's book also, and thought the "Hints to Implementors"
    was a great idea (there should be a 10 Most Deadly Sins RFC [like don't
    [Stuff Deleted]


This spring, I used Doug's book as a supplementary text for a computer
networking course (I had a prepublished version) with Stallings book
as the main text. As a supplementary text, it turned out excellent as
students understood the ARPA internet protocols well. However, I am
still not sure if it will be a satisfactory text by itself for a
course because of its lack of treatment of fundamental networking
principles, lack of good exercises, and its treatment of only TCP/IP.

Is anybody planning to use it as the sole text for a course ? 

-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

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 23:00:02 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   finding routes

I agree in theory that hosts shouldn't know anything about routing.
However I find that in practice, BSD-derived implementations make it
hard to carry that out.  Other implementations seem to have similar
problems as well, but I know BSD the best.

The simplest approach is to set a default route for a nearby gateway
and depend upon it for redirects.  The problem is, what if one of of
the gateways goes down.  There is no way to get a crashed gateway to
redirect you back to the default, nor is there any way to handle a
default gateway going down.  However if you are more concerned with
lines going down than gateways going down, that's a reasonable
alternative.

This is under 4.2.  Under 4.3, routes will be declared down if a TCP
connection is about to time out.  This means that routing will return
to the default.  Theoretically I suspect one could specify several
defaults, and if the first one goes down another one would be tried,
but I haven't verified that.  Our problem is that this only works for
TCP.  NFS doesn't talk to the routing layer, so if you have a path
that is used only by NFS, and the route goes down, you lose.

We are currently using a default with a metric of 0.  This is effect
makes our machines treat everything as local, and issue ARP's for
everything.  Since our gateways do proxy ARP, that works.  However
even this has a problem: ARP entries time out if they aren't used, but
if somebody keeps retrying something, a bad ARP entry will stay there
forever.  In my view, 4.3 has made enough improvements that the
default gateway approach is probalby better for 4.3-based code, while
the proxy ARP approach is probalby better for 4.2-based code.  But
none of the approaches is a complete solution.

Running RIP in passive mode sounds like it would be a complete
solution, if your gateways run RIP.  However it is going to create
performance problems for networks with lots of diskless nodes.  That's
because when a packet arrives, all your workstations will have to swap
in their copy of routed, and so you'll have lots of synchronized
network traffic, which will likely saturate your network.

I understand that a subcommittee of the IETF is working on this
problem, and plans to add one or two new ICMP types.  Unfortunately,
this is likely to take several years to make it through the vendors
(some of whom don't even do subnets yet).  This is probably the
biggest disadvantage of TCP/IP.  It seems to take someone with a
reasonable knowledge of routing to set up a network and add hosts to
it.  This contrasts with DECnet, where about all you have to do is set
the DECnet address, and routing is handled automatically.  I regard
TCP/IP as a better protocol for larger networks, and the newer TCP/IP
routing technology as better than DECnet phase IV (but probably not
phase V).  But I have to say that TCP/IP networks of small or moderate
size appear to be harder to set up and to diagnose routing problems
in.

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 23:06:59 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP

I certainly agree that 802.3 is useless, and we should have stuck with
DEC-Intel-Xerox Ethernet.  However what seems to be happening in
practice is that older protocols are ignoring 802.3, and newer ones
are using it.  Thus no incompatibility actually happens.  That is,
TCP/IP, PUP, and DECnet phase IV are using the Ethernet standards,
while ISO and DECnet phase V will presumably use 802.3.  For token
rings, etc., that have no existing base of TCP/IP implementations, it
appears that only an 802.3 encapsulation will be used.  So we should
not have compatibility problems in practice.  That assumes no vendors
get overly eager in their standard-following and try to do an 802.3
encapsulation for Ethernet.  HP did that, and lost obviously enough
that I think other vendors will be discouraged from following suit.

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 May 88 23:57:40 GMT
From:      gamiddleton@watmath.waterloo.edu (Guy Middleton)
To:        comp.protocols.tcp-ip
Subject:   subnetting supported by Sequents?

Does anybody know whether the Sequent's version of Unix (called "Dynix", I
think), supports subnetting yet?

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 00:58:51 GMT
From:      jjkkrr@FORD-COS1.ARPA (J. Kevin Rohan)
To:        comp.protocols.tcp-ip
Subject:   (none)



	I'm looking for, if it exists as a standard, a document that
	describes the algorithm for mapping an IP class B or class C
	address into an X.25 address.  I've got RFC 796 (that to the best
	of my knowledge has never been updated) and it doesn't cover X.25.
	I also have the NETINFO:X25.DOC and it covers the DDN's class A IP
	address, but I can't seem to find anything anywhere on the mapping 
	of class B or C.  It seems like gateways everywhere support this 
	but where's the algorithm???

						Thanks in advance!!
						   Kevin Rohan
						jjkkrr@ford-cos1.arpa

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 02:39:35 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Many things on ethernet together???

When I saw the first message asking about how to deal with
Pups on 802.3 networks (the old Ethernet type code for Pup
is a legal 802.3 length code), I thought to myself "nobody
runs Pup on 10mb nets any more" (I wrote the code in the
Stanford Unix Pup package to handle the 10mb stuff, and
since this is apparently the only Pup code for Unix systems,
I thought I knew something.)  Then Darrel VanBuer writes
that there's a new, "legal" code for Pup and Pup ARP.

Does this mean that people still use Pup (outside of Xerox?)
Wow!  (Dave Boggs is going to love this one.)  Does anyone
really care if Pup coexists with 802.3 systems?  If so, I'm
doubly surprised.  Does anyone want the same host to speak
Pup and 802.3 ('cause otherwise the Pup hosts should drop
the 802.3 packets due to bad checksums, and vice versa)?

Sorry this is on TCP-IP, but I've noticed a tendency towards
protocol archeology this week, and Pup certainly is a relic.

-Jeff

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 May 88 10:36:28 EDT
From:      Doug_Nelson@um.cc.umich.edu
To:        kwe@bu-cs.bu.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Subnetting [struct Enet addr]
In response to Kent England's question:
>       It seems so obvious to me that a hierarchically structured
> address space in Ethernet (read 802.x) 48 bit addresses would be a
> great improvement over the current kludged 48 bit flat vendor-assigned
> address space coupled with the 32 bit IP address space that I wonder
> why the issue never comes up.  I know all the obvious problems with
> structured Ethernet addresses, but everytime I look at the issue it
> seems to me that structured Ethernet/IP (read 802.x) addresses would
> be a great improvement over flat address space.
>
>       I think the 802 spec allows structured addressing, yes?  Why
> is there no hint of movement in this direction?  Waiting for ISO?  Or
> have I failed to grasp some essential difficulty with this?  Comments,
> please.
 
The most obvious difficulty with it is that it only fits the needs
of IP.  Many systems handle multiple protocols; they would be forced
to constantly change their Ethernet address.  And for what?  To
save 4 bytes on a high-speed medium, where packets are often padded
because they're too short?  And what do you do on other media where
you have zero to two bytes of addressing?
 
Note that DEC *is* using structured addresses for Ethernet.
Note also that DEC is moving *away* from this in the future,
since ISO addresses are too big to fit in Ethernet addresses.
And that's where we're heading as well!
 
Doug Nelson         Michigan State University    Computer Lab
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 May 88 15:33:53 PDT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        tcp-ip@sri-nic.arpa
Subject:   Subnetting clarified
It figures that a heated discussion of subnets would start about 3
hours after I left the country for 10 days.  Anyway, at the risk of
repeating some things that some of the wiser participants have already
stated, I'd like to clarify a few points.  I feel moderately justified
in doing so; since I wrote the standard.

First, I'd recommend that, before spouting off, everyone read
	RFC950 - Internet Standard Subnetting Procedure and
	RFC917 - Internet Subnets
RFC950 is the Standard; RFC917 contains more explanatory information.

Now, I am talking about an "Internet Standard", not "the answer to
everyone's problems."  This means that some people may find that a
different approach would be a better solution to their specific
problems.  That is fine, but the subnetting standard was written to be
a good solution for most people's problems.  Not only that, we felt it
vitally important that it be widely adopted; thus, it had to be easy to
implement and it had to be a single solution.  Nothing prevents the
owner of an Internet network from running a different subnetting
mechanism ... but if you use the standard mechanism, you can go to your
vendor and complain if they aren't meeting the standard.

One general complaint that people often raise is that it's hard to
produce optimal routes under this standard.  THAT IS PRECISELY THE
POINT!  To discover optimal routes, you need oodles of information.  To
keep the Internet managable (and to keep the routing tables from
exploding), we need to keep the amount of routing information as small
as possible.  Optimal routing and a managable Internet are, to a
certain extent, inherently adversarial goals (this is an
oversimplification).  Basically, if the routes you would get by using
subnets are too awful, then you should consider getting more than one
network number.

The whole point of subnetting, then, is to hide local information from
the global community; put another way, it is to impose a hierarchy on
the routing information (and address management) so as to limit the
remote impact of local complexity.  The subnet structure of a network
must be (is intended to be) completely invisible outside that network.
Thus, it makes absolutely no sense to ask about how to route directly
to the right subnet of somebody else's network, or to broadcast to a
single subnet of a remote network, etc.

Now, on to the mechanism:

Before the Standard (RFC950) was issued, an intense discussion went on
about how best to design it.  One group argued for "self-describing"
addresses; i.e., you could look at an address and (without any other
information) determine how bits were allocated to subnet and host
fields.  To make a long story short, this method lost.  Instead, the
remarkably simple concept of an Address Mask is used.  With each
network is associated an Address Mask that is used to determine which
bits select a specific host, and which select a specific data-link
network.

While it is in theory possible to associate different Address Masks
with different subnets of a network (in conjuction with a self-encoding
scheme such as the one used to separate Internet Address Classes), this
is not what we intended when we wrote the Standard.  (I'm not sure we
managed to explicitly prohibit it.)  It is certainly possible for a
single host to be connected to two different networks (i.e., top-level
networks) each with a different Address Mask, and so in the host
software the Mask should be stored per-interface (as it is in 4.3BSD).
In such an implementation, it might be possible to use different masks
for different subnets of a single network, but I would not recommend
this, since you might find that other implementations cannot handle
this; the Standard does not explicitly require that they do so.
Moreover, as it has been pointed out, there are subtle problems with
this, since in order for a host to choose the right netmask for an
outgoing packet, it has to know the self-encoding scheme as well.

If you really need a single "big" subnet and a lot of little ones,
consider getting two network numbers.  I find it unlikely, however,
that a single subnet with more than a few hundred hosts on it is going
to be easily managable.

Host software that does not allow the Address Mask to select an
arbitrary division of bits between host field and subnet field (e.g.,
software that requires these fields to be a multiple of 8 bits wide) is
not in compliance with the Standard.

Proxy ARP is (in my opinion) not a good solution to the routing problem
in general.  Rather, it is a way for smart gateways to help dumb hosts;
a "dumb host" is one whose software cannot handle subnetting.  If
you're stuck with such a host, your first step should be to complain to
the software vendor, but Proxy ARP will carry you until the vendor
makes good.  One obvious problem with Proxy ARP is that it doesn't make
any allowance for gateway crashes.

One of the intended effects of the Address Mask mechanism is to
insulate hosts, as much as possible, from the details of routing.  I
applaud the efforts to try to separate the "what are my neighbor
gateways" question from the "what is the network topology" question.
Passively listening to RIP broadcasts to learn a subset of local
gateways might be a good idea, but peering inside those RIPs seems
like a bad idea.  I also like the idea of a multicast request that a
host can use to discover its neighbor gateways; there are trivial
solutions to the collision problem.  (ARP does not seem to be the right
mechanism for this, because it doesn't distinguish between "responder
is THE target" and "responder is A first hop to the target".) Of
course, on a non-broadcast medium, other gateway-acquisition
mechanisms are necessary.

I'll close by rephrasing a point I made earlier: the Subnetting
Standard is not meant to be the perfect solution to everyone's
problems.  It is a pretty good solution to most people's problems, and
it is a standard so you can hold vendors to it.  Trying to take
perverse advantage of ambiguities in the standard is like taking
advantage of an undocumented effect of an instruction code; you will
regret it later on.

-Jeff
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 11:12:17 GMT
From:      jsloan@wright.EDU (John Sloan)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: Plenum-Rated Ethernet Transceivers

in article <410190444@nwnexus.WA.COM>, edm@nwnexus.WA.COM (Ed Morin) says:
> It turns out that the transceivers can be put into "air handling *spaces*"
> (like ceilings), but *not* in actual ducting (i.e. main air supplies, etc.).

I'm not sure there's much of a distinction in modern buildings. Many
(including ours) use ductwork to deliver air to offices, then use
the plenum (the air space above the ceiling) as an air return. Since
the fire code is concerned about smoke and noxious fumes from burning
materials (particularly plastic), which are the major causes of deaths
in fires, spreading to other parts of the building (also making locating
the fire very difficult), it would seem to me to be six of one, half
dozen of the other.

It sounds more to me like Cabletron was trying, not very successfully,
to come up with a plausible explanation. Second worry of the day: I
recently realized that some of the telephone closets are open to the
plenum in the top... i.e. no ceiling. So, like, is that a plenum space
or what?

Third worry of the day: trying to explain to our new department chair
why this is all so complicated ("why can't you just run a cable?"
"because I don't want my a** sued off.").

-- 
John Sloan, The SPOTS Group    Wright State University Research Building
CSNET: jsloan@SPOTS.Wright.Edu  3171 Research Blvd., Kettering, OH 45420
UUCP:  ...!wright!jsloan                +1-513-259-1384  +1-513-873-2491
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 17:00:58 GMT
From:      ted@ultra.UUCP (Ted Schroeder)
To:        comp.protocols.tcp-ip
Subject:   Re:  Sources V.3.3 / 68020 TCP Stuff


Please add me to the list of people also looking around for sources for
TELNET, FTP, etc., etc., etc.

      Ted Schroeder                   ultra!ted@Ames.arc.nasa.GOV
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 ted@Ultra.COM
      408-922-0100

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 17:11:03 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Third TCP-IP Book?


Philip,  Unfortunately splitting the book in half does not mean 
dropping the price accordingly...

Probably would only be able to drop
the two halves to the high 20s.

Dan
-------

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 17:46:40 GMT
From:      ecc@spice.cs.cmu.edu (Eric Cooper)
To:        comp.protocols.tcp-ip
Subject:   Remote boot/debug protocols?

Are there any protocols that support both bootstrapping and tele-debugging,
with the machine-dependent parts nicely modularized?  For the debugging
functionality, I'm looking for something that could be put between the front
and back ends of dbx or gdb.  Any leads appreciated.

					Eric Cooper (ecc@cs.cmu.edu)
					Computer Science Department
					Carnegie Mellon University

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 18:47:53 GMT
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   Re: Need info on Ethernet products for the IBM AT and Sun

In article <5503@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes:
>We would like to network our IBM AT to one of our Sun Microsystems
>computers.  The ideal method is to just plug the AT into the Sun's
>ethernet network using an add--on ethernet interface card.  Someone
>recommended the Western Digital Ethercard for this purpose.

This is a nice cheap high performance hardware configuration. But...

>But what kind of software is available for the IBM AT that will let me
>communicate with Suns?  We would like to do basic things like file
>transfer, finger, telnet and maybe hardcopy on the Sun from the AT if
>that can be done.

I have been (am using right now!) Sun's PC-NFS. I have personally done
file transfer via FTP and telnet. It is supposed to do remote printing
and NFS, I have not tried them. 

I was at first very pleased with the product, the telnet worked much
better for me than Phil Karn's ka9q because I assume I did not have a
good termcap for the PC's ansi.sys. PC-NFS emulates a vt-100 to a
large degree. 

At present I do not believe PC-NFS works with the WD interface. I am
using it with a (brain-damaged) 3Com interface. 

However, with use, cracks and problems show up in PC-NFS. Some are
real problems, some might be called a nit but anyway, the product
could be improved. 

1) No support for multiple telnet sessions like ka9q.
2) No ftp server like ka9q.
3) ftp client blows up on mget with a small number of files, says
"Arguments too long".
4) ftp client dies if you go back to telnet too long.
5) Host can't set tabs like a real VT-220 does (and I assume a VT-100 does).
6) No rlogin.
7) No .netrc for ftp means you always have to explicitly login.

I've been waiting four days for an answer from Sun user support on 3).
I expect they'll tell me "don't transfer so many files".

>Would TOPS for the AT provide anything that I need?  TOPS would have
>to be run on the Sun I suppose and that's probably expensive.  Are
>there hardware interfaces for the AT that will let me communicate with
>Appletalk (well there must be since people do connect ATs to
>Appletalk)?

Believe it or not, TOPS Corp (a division of Sun) makes a hardware
interface for the AT that lets you talk Appletalk. But then if you
want to talk to the Sun you'd need a Kinetics box and either Appletalk
on the Sun or something like NCSA on the AT. 

I don't know that TOPS/Appletalk would do anything for an AT. The cost
might be lower, but with the WD interface that's not clear. The
performance is certainly not going to be nearly as good. 

-- 
Make Japan the 51st state!

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 20:40:11 GMT
From:      castillo.osbunorth@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Proteon's behaviour



I installed a Proteon router running standard TCP/IP software to connect our
back bone net in our building with a private net in the same building (no
external gateway, simply a router connecting 2 disjoint subnets).

We have noticed some behaviour which seems to be a normal operation on the
gateway, but that it is very annoying.
It seems that the Proteon does some self testing of both of its Ethernet
interfaces and other internal hardware by sending small trash packets to itself
every so often through both interfaces.
The frequency of such tests is often enough that it is noticibly consuming
precious bandwidth already at a premium in our backbone which is carrying a lot
of XNS traffic.

Has anyone experienced such behaviour? Is there a way to reduce the frequency of
the tests?

** julio

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 21:23:21 GMT
From:      gutman@manta.NOSC.MIL (Lewis M. Gutman)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Transport Level Interface

A month or two ago I read something about the Transport Level
Interface, being developed, I believe, at Bell Labs.  My 
understanding was that it offered a standard interface to 
tcp.  Can anyone shed any light on TLI?  Can anyone suggest
a reference?  If TLI is not a software interface to tcp, can
anyone tell me whether there is such a thing?  Reply directly,
please.  

Thanks in advance.

Lew Gutman
<gutman@manta.nosc.mil>

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      19 May 88 22:17:21 GMT
From:      ehrlich@blitz (Dan Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Competition for Bridge

In article <8805171310.AA03117@tut.cis.ohio-state.edu> tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday) writes:
>
>   Dan,
>
>     Could you give me a name and number for someone at Encore and CISCO to

I have a number for Encore, but will have to track down CISCO.
Our sales rep for Encore is Aaron Silberstrom, +1 301 762 8711.
Encore just announced a 32 port version of there server with a
faster CPU, more memory, etc.  Cost: $8,500.

--Dan
Dan Ehrlich <ehrlich@blitz.cs.psu.edu>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 00:55:54 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   OSI CLNS and the future of networking

Helpppp! I am trying to understand where networking is going. I 
suspect I'm not the only one. As an investigative measure I present 
a guess based largely on rumour. Will the people who know please 
comment.

The OSI CLNS (ConnectionLess Network Service) is basically just 
DoD's IP with minor changes (like a bigger address field). The 
objective is obviously to replace IP with CLNS. Presumably a subset 
of CLNS addresses is reserved for (and in simple arithmetic relation 
to) IP addresses. This will allow a mix of CLNS and IP as long as 
the backbone is CLNS. We can imagine that during the cutover there 
will be arrangements like this:

        IP                 CLNS                 IP
    IP1----IP/CLNS-gateway------IP/CLNS-gateway----IP2

Where IP1 and IP2 are ethernets still using IP. They shouldn't see 
any change talking to each other. The question then is how they will 
talk to people who have made the cutover. Presumably the gateways 
will have to have tables (presumably built dynamically by querying 
relevant servers) of CLNS to IP addresses: CLNS hosts which wish to 
be able to talk to IP hosts will have to have their IP-equivalent 
address registered so the gateway has a replacement IP address to 
use for that CLNS address when packets enter the IP world (and 
contrari-wise). Those gateways will need fast processors in them.

If CLNS hosts are going to talk to IP hosts (and this is absolutely 
essential if the whole thing is going to get off the ground) then 
obviously the first middle level protocols to be implemented will be 
TCP/CLNS and UDP/CLNS, and the associated application level 
protocols. This should be a trivial modification of existing TCP/IP 
and UDP/IP code. 

The nice thing about going to CLNS is that you can then start 
running other high level protocols. In particular CLNS/TP4 will give 
access to the OSI higher level protocols [I know the X.400 standard 
says that it must run only over TP0 and only over X.25 but this is 
just a pathetic attempt by the PTTs to force people to use X.25. No
sensible implementations will enforce this restriction. DECs 
implementation (MRX) currently allows TP4 over ethernet].

The next interesting thing is that DEC says DECNET Phase V will work 
over CLNS. So presumably VAXes (and other computers) on the CLNS 
Internet will be able to talk DECNET to each other.

That's all very well, but I would like to understand how CLNS over 
X.25 coexists with the existing CONS (ConnectionOriented Network 
Service) over X.25. I guess they just use different Subaddress or 
Protocol-id or Call User Data. I am also not sure how CLNS over
802.3 fits in with existing OSI over 802.3. Presumably the packets
will have CLNS sender and destination addresses in them (the new IP
addresses). That certainly isn't what is in them now. 

Bob Smart, CSIRO Division of Information Technology, Australia

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 May 88 06:51:29 CDT
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CORNELLC.CCS.CORNELL.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   TCP/IP platform.
We are in the early stages of implementing a campus fiber optic backbone
that will link a variety of equipment together using TCP/IP as the
protocol of choice.  We are also connecting to one of the NSF regional
nets, SURANET, sometime this summer.  As is the case with most university
environments, we have a rather chaotic mix of hardware and software that
we are trying to bring together.  We are also fairly new at the TCP/IP
game and have many more questions than answers.

In general, I am looking for a UNIX box such as a MicroVAX, IBM RT or
SUN workstation to fulfill several requirements.  I want a stable,
up-to-date TCP/IP implementation that I can use as a benchmark when
diagnosing problems.  That is, I want the TCP/IP on this box to be
a known commodity that I can depend upon to perform as it should.
Next, I want to have available a large suite of software "goodies" that
I can use in conjunction with the network to gain experience with the
capabilities of TCP/IP.  Things in this category might include a file server
capability like NFS, and network monitoring/diagnostic software.
Next, I want this box to be able to provide some routine, network-wide services
such as domain name server and time server.  And finally, I want this to be
a box from a vendor that is likely to stay on the leading edge of TCP/IP and
OSI developments.

I would appreciate any suggestions as to vendor, hardware and software
that might satisfy my requirements.  Although I would hope to spend
less that $20,000 for such a system, please do not let cost affect your
recommendations.

Thanks,

Mike Rackley
Mississippi State U. Computer Center
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 02:06:35 GMT
From:      bae@ati.tis.llnl.gov (Hwa Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: SendMail

In article <8805180903.aa03398@CAD.USNA.MIL> tsmith@USNA.MIL ("Tim G. Smith", Mechanical) writes:
>We currently use MMDF as our mail handler but are in the process of
>switching to sendmail as sendmail seems to be emerging as the
>"standard" mail handler.
No offense.  But in my view MMDF has far better design than sendmail.  
I don't see why you would go from MMDF to sendmail.  The other way around
makes much more sense.  I guess I've actually lived long enough to 
hear someone say "I LIKE SENDMAIL!".  sendmail is a very sickening 
piece of software - overblown, unnecessarily complicated, 
huge Mo.Fo.  I don't know how you are using MMDF but it's
concept is closer to modern mail system models like X.400 where several
delivery mechanism can be handled transparently.  MMDF allows you to
have separate processes for mail delivery channels which can be totally
different.  One of the channels may be sendmail since it does implement
SMTP.  I would prefer to use simpler SMTP mailer though.  It's truely
incredible to see how a Simple Mail Tranfer Protocol can be implemented
in such Complex ways (as in sendmail), which tries to do too much.
I think I've work on sendmail code enough to know that it is the ultimate
example of the BSD mentality - 10 times more flexible but 100 bigger
and more complex.
-----
Hwa Jin Bae          | The Devil made me do it...yeah, that's right!
Control Data Corp.   | (415) 463 - 6865
4234 Hacienda Drive  | bae@tis.llnl.gov			   (Internet)
Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae    (UUCP)

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 02:13:31 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb vs. smart host routing

Proxy ARP can be used for all routing, not just subnet routing.  The
idea is to give your hosts default routes that tell them to treat
everything as on the local cable.  This is done in Unix by doing
  route add 0.0.0.0 YOURADDRESS 0
where YOURADDRESS is the Internet address associated with your
Ethernet interface (if you have more than one, the one you want
used as default).  By using a metric of 0, you tell the system to
treat this route as on the local cable, so it issues ARP's rather
than using a gateway.  It is of course possible that some TCP/IP
implementations don't have an equivalent kludge, but many of them
seem to.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 05:14:18 GMT
From:      hagan@scotty.dccs.upenn.edu (John Dotts Hagan)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong's TCP/IP


The University of Pennsylvania Data Communications and Computing Services
group has chosen WIN/TCP for VMS as the best solution for VMS TCP/IP.

We are not using any of them as Domain Name Servers, but they all work
very well as DNS clients.  In fact, the system works better than standard
4.2bsd (many 4.2 TCP/IP problems are fixed).

--Kid.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 11:27:41 GMT
From:      piet@cwi.nl (Piet Beertema)
To:        comp.protocols.tcp-ip
Subject:   Re: SendMail


	>No offense.  But in my view MMDF has far better design than sendmail.  
	>I don't see why you would go from MMDF to sendmail.  The other way around
	>makes much more sense.  I guess I've actually lived long enough to 
	>hear someone say "I LIKE SENDMAIL!".  sendmail is a very sickening 
	>piece of software - overblown, unnecessarily complicated, 
I like sendmail too, for various reasons.
But this is not exactly a newsgroup to
fight out a largely theological discussion.

-- 
	Piet Beertema, CWI, Amsterdam
	(piet@cwi.nl)

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 11:51:29 GMT
From:      RACKLEY@MSSTATE.BITNET (Mike Rackley)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP platform.

We are in the early stages of implementing a campus fiber optic backbone
that will link a variety of equipment together using TCP/IP as the
protocol of choice.  We are also connecting to one of the NSF regional
nets, SURANET, sometime this summer.  As is the case with most university
environments, we have a rather chaotic mix of hardware and software that
we are trying to bring together.  We are also fairly new at the TCP/IP
game and have many more questions than answers.

In general, I am looking for a UNIX box such as a MicroVAX, IBM RT or
SUN workstation to fulfill several requirements.  I want a stable,
up-to-date TCP/IP implementation that I can use as a benchmark when
diagnosing problems.  That is, I want the TCP/IP on this box to be
a known commodity that I can depend upon to perform as it should.
Next, I want to have available a large suite of software "goodies" that
I can use in conjunction with the network to gain experience with the
capabilities of TCP/IP.  Things in this category might include a file server
capability like NFS, and network monitoring/diagnostic software.
Next, I want this box to be able to provide some routine, network-wide services
such as domain name server and time server.  And finally, I want this to be
a box from a vendor that is likely to stay on the leading edge of TCP/IP and
OSI developments.

I would appreciate any suggestions as to vendor, hardware and software
that might satisfy my requirements.  Although I would hope to spend
less that $20,000 for such a system, please do not let cost affect your
recommendations.

Thanks,

Mike Rackley
Mississippi State U. Computer Center

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 May 88 16:13:30 EDT
From:      Ross Callon <rcallon@GOVERNMENT-CENTER.BBN.COM>
To:        dpowles@CCD.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA, rcallon@bbn.com
Subject:   Re: connecting Internets?
Drew;

I think the answer is a qualified yes.  There are several "sub-issues"
however.  In a sense the issues involved in interconnecting multiple
existing "Internets" are the same as those in having the Internet grow to
encompass a large number of administrative domains, except for the added
problem of address overlap (which is probably NOT the worst problem).

In terms of address overlap, the solution depends upon whether you use the
DoD IP or the ISO IP.  With the DoD IP, I am not aware of any work on how
to map between two overlapping inconsistent address sets.  The obvious
choice would be to more or less hand-configure some sort of translation,
and have big tables in the gateways on the boundary.  Exactly how this is
done may depend on whether you run out of network numbers for any
particular class of network address.  For example, if a class A address on
one side maps to a class B address on the other, then the host part of the
address would also have to change.  All of this seems potentially ugly.
The ISO protocol, on the other hand, comes complete with globally unique
addresses.  For example, consider the proposed ways in which addressing
could be done with the ISO IP in the DoD Internet (see RFC986, IDEA003, and
a revision of both which is about to come out as a new RFC).  Here the
first three octets of the address specify "DoD Internet", and addresses are
globally unique even with respect to Internets in some other part of the
world.

Another potentially more serious question regards how to route in a future
world of multiple "Internets" (or a multi-domain Internet).  It can be
assumed that most of the administrative domains in the world will have
strict restrictions on what sort of traffic they are willing to carry for
what users.  For example, a particular domain may be willing to carry any
traffic which is strictly internal, traffic between this domain and
neighbors only for specific users and/or applications, and transit traffic
only for a small number of outside domains and specified applications.  The
domain may be very willing to carry electronic mail traffic for their main
competitor, because they want to make copies for themselves (the main
competitor may, for the same reason, be unwilling to use this service).

One can easily envision all sorts of other "policy constraints" affecting
routing.  Thus routing will need to look at all sorts of administrative and
policy considerations.  The IETF Open Routing working group is currently
thinking about how one may do this.  IDEA003 represents a first draft of
the requirements for inter-AS (or Inter-domain) routing, but is only in
draft form (there is a list of proposed updates to be made in the future).
We are currently working on several proposals for how to actually do
routing in this environment.  The Autonomous Networks Task Force is also
working on related issues.

There are other issues that are likely to come up when multiple "Internets"
are interconnected.  For example, there may be a need for congestion
control to be sensitive to administrative policies and contractural
arrangements.  

Ross
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 12:39:11 GMT
From:      ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP (was Re: Dumb vs. smart host routing)

In article <882@kaos.UUCP> romkey@kaos.UUCP (John Romkey) writes:
>
>Bill,
>
>I hate to do this, but I don't like proxy ARP at all.
 ...
>First, there are too many network media that don't use ARP for my
>taste. ARPANET, X.25, ProNET-10. Maybe FDDI won't? 
I suppose I should give Phil Karn a chance to say this first, but
AMPRnet (Amateur Packet Radio, network 44) generally won't - hidden
terminal problems and unreliable broadcast performance make it impractical.

Unfortunately, ARP has become too popular, so that people almost always think
of trying to use it to help with routing.
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 May 88 09:34:45 +0200
From:      "Alain FONTAINE (Postmaster - NAD)" <FNTA80%BUCLLN11.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RFC821/RFC822 route syntax.
Could somebody tell me if I do read correctly a correct version of
RFC821 and RFC822 ? From what see the syntax for the route part
of a route-address is :
in RFC821 :   @domain1,@domain2,@domain3:
in RFC822 :   @domain1@domain2@domain3:
Maybe this is clear for everybody except me...     Thanks.  /AF
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 May 88 22:00:46 PDT
From:      satz@clash.cisco.com
To:        jjkkrr@ford-cos1.arpa (J. Kevin Rohan)
Cc:        tcp-ip@sri-nic.arpa
Kevin,

Someone was supposed to write up an RFC describing the mapping used for
class B and C addresses. What is currently being used in the cisco DDN X.25
implementation is:

	class A: N.H.L.I
	class B: N.N.H.I
	class C: N.N.N.HI

Where N represents the network number. H represents the PSN port number. L
is the logical host field and is still zero. I is the PSN number. For class
B addresses, the H field uses the unused L field.  For class C addresses,
the H field lies in the upper four bits of the last octet and the I field
in the lower four. I don't know of anyone who has a class C PSN network.

Hope this helps,

Greg Satz
cisco
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 15:00:59 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   LOOPBACK Net Number

Qeustion to all you network GURU's:				05/20/88

Is there a standard for a loopback address.  On BSD machines I've seen
it is usually 127.0.0.1, however EXCELNA defaults to 127.0.0.0.  Both
let you override the default.

I did not see any references to loopback addresses in the RFC index. Any
comments or suggestions on where to look?

				Thanks,
------------------------------------------------------------------------
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
------------------------------------------------------------------------

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 15:54:49 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   Re: hosts and gateways and protocols

(I said I listen for RIP packets to find a gateway.  Frank Kastenholz
responded...)

> This assumes that your host can understand that the packet is a RIP
> packet. If my routers use another IGP then the hosts will not know that
> it is an IGP packet so they can not "backtrack" to the source of the
> packet and get a router.

Yes, I understand that.  That's why I would like one protocol which
says "I am a router" that *everyone* uses.  Today, however, there is
no such protocol.  As a practical matter I use RIP (and wouldn't mind
using a few more).

(I said...)
> >I also feel for those souls whose routers occasionally crash, and who would
> >like routes to switch automatically.  I don't believe that just because
> >you need this capability once per day that should exclude it from being
> >automated.
 
> Unfortunately I must strongly disagree with the last sentence. TCP/IP is
> entering the non-technical world very rapidly. The company that I work
>...
> and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The
> recovery mechanism is required for a very simple reason - money. ...

Sorry.  I was in "poor English" mode.  You and I are in total agreement.
I worded my sentence poorly.

Greg Minshall
Kinetics, Inc.
(415)947-0998			...ucbvax!mtxinu!kinetics!minshall

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 16:05:48 GMT
From:      pdb@sei.cmu.edu (Patrick Barron)
To:        comp.protocols.tcp-ip
Subject:   Re: SendMail

In article <22208@tis.llnl.gov> bae@ati.tis.llnl.gov (Hwa Jin Bae) writes:
>I don't know how you are using MMDF but it's
>concept is closer to modern mail system models like X.400 where several
>delivery mechanism can be handled transparently.  MMDF allows you to
>have separate processes for mail delivery channels which can be totally
>different.

sendmail will let you do exactly the same thing - it's not just a big,
complicated SMTP implementation.  It can do UUCP, BITNET, SMTP, local
Unix mail, etc.  It can let you vary how (or if, at all) a message gets
delivered depending on what the address looks like and/or who the sender is.
You can define different mailers which use the same delivery mechanism but
with different parameters.

I'll certainly admit that it's very complex, probably much more so than
it needs to be - especially if you have to hack the configuration file.

[Usenet followups redirected to comp.mail.sendmail]

--Pat.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 16:19:24 GMT
From:      bradg@zaphod.UUCP (The Rogue Warrior)
To:        comp.protocols.tcp-ip
Subject:   Getting RFCs (was: RIP, gated reply summary)

In article <2875@emory.uucp> ospwd@emory.uucp (Peter Day {EUCC}) writes:
>RFCs are available from a number of sources, but in particular,
>may be obtained by sending a note to
>service@sri-nic.arpa with Subject: RFC nnn
 ^^^^^^^^^^^^^^^^^^^^
Could someone please give me the corresponding UUCP address if one exists
or, if not, a way to get from UUCP to the ARPAnet?  Thanks.

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 16:45:47 GMT
From:      peter@xios.XIOS.UUCP (Peter Manson)
To:        comp.protocols.tcp-ip
Subject:   PING with source/record route

A while ago there was an article here from someone who had modified
PING to provide source and/or record route functions (and maybe some
other things in addition to 4.3 PING).  Unfortunately, I didn't save it.

If anyone has information on this (or better still, the source or
the modifications), please send me mail.  General info about PING
and other enhancements to it would also be appreciated.

Thanks very much.
----------------------------------------------------------------------------
Peter Manson			|
XIOS Systems Corp.		|
150-1600 Carling Avenue,	| peter@xios.uucp		from UUCP
Ottawa, Ontario			| xios.uucp!peter@uunet.uu.net	from Internet
K1Z 8R8				|
CANADA				|
(613) 725-5411			|
-- 
----------------------------------------------------------------------------
Peter Manson			|
XIOS Systems Corp.		|
150-1600 Carling Avenue,	| peter@xios.uucp		from UUCP
Ottawa, Ontario			| xios.uucp!peter@uunet.uu.net	from Internet
K1Z 8R8				|
CANADA				|
(613) 725-5411			|

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 17:42:45 GMT
From:      norm@atom.hpl.hp.COM (Norman Kincl)
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP


> I certainly agree that 802.3 is useless, and we should have stuck with
> DEC-Intel-Xerox Ethernet.  However what seems to be happening in
> practice is that older protocols are ignoring 802.3, and newer ones
> are using it.  Thus no incompatibility actually happens.  That is,
> TCP/IP, PUP, and DECnet phase IV are using the Ethernet standards,
> while ISO and DECnet phase V will presumably use 802.3.  For token
> rings, etc., that have no existing base of TCP/IP implementations, it
> appears that only an 802.3 encapsulation will be used.  So we should
> not have compatibility problems in practice.  That assumes no vendors
> get overly eager in their standard-following and try to do an 802.3
> encapsulation for Ethernet.  HP did that, and lost obviously enough
> that I think other vendors will be discouraged from following suit.

Are you not confusing 802.3 with 802.2?  802.3 (physical layer) is
essentially identical to Ethernet physical layer (the grounding pin is
different and there is one other difference in there somewhere).  It is not
hard to make a card that can be fully compatible with both.  Most cards
these days don't really care if they are connected via an transceiver cable
to a transceiver (Ethernet) or via an AUI cable to a MAU (802.3).

802.2 (data link layer) is where the problem comes in.  Though you can have
a system that speaks both quite fluently (eg. HP9000 or cisco box), most
systems do not do that and provide only one of those data link layers
(usually Ethernet).

(There is no such thing as 802.3 token ring---that comes under 802.5)

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 17:48:01 GMT
From:      miket@ccicpg.UUCP (Mike Tracy)
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP


in article <14933@sgi.SGI.COM>, vjs@rhyolite.SGI.COM (Vernon Schryver) says:
> 
> In article <1080@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes:
>> I see only one easy answer to the gratuitous compatibility problems
>> imposed by 802.3: IGNORE IT!  ...
> 
> Yes, but...some vendors are already supporting it.  I'm told by some of
> our customers that Gould/SEL machines can do either 'Ethernet 1 or
> 802.3' (meaning either lengths or types), depending on boot-time
> configuration, and cannot send even raw ethernet packets of one kind
> when configured for the other.  

Are you sure they don't mean ethenet 2 ?  Many vendors claim to be 802.3
compatable but actually are only compatable up to the frame format.
All of the electrical stuff, CSMA/CD, etc. is 802.3 but they use they
standard ethernet frame format (i.e. type instead of length).
Probably, if they are running Unix, they are ethernet 2.  Otherwise, it
makes it hard to talk to other Unix boxes. :->


-- 
Michael D. Tracy	CCI Computers 
(714)458-7282		9801 Muirlands Boulevard
			Irvine, CA 92718
uunet!ccicpg!miket

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 19:48:36 GMT
From:      ihm@nrcvax.UUCP (Ian H. Merritt)
To:        comp.protocols.tcp-ip
Subject:   Re: Toothpaste, but also *disinfectant*!

CDBP01@VAXD.STRATHCLYDE.AC.UK says:
>Competition time: how many uses for liquid TCP could be found for Real TCP?

It seems that a liquid TCP could do wonders for the fragmentation
problems commonly found on the network.  Consider how easy reassembly
would become (;->)


	-i

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 20:13:30 GMT
From:      rcallon@GOVERNMENT-CENTER.BBN.COM (Ross Callon)
To:        comp.protocols.tcp-ip
Subject:   Re: connecting Internets?

Drew;

I think the answer is a qualified yes.  There are several "sub-issues"
however.  In a sense the issues involved in interconnecting multiple
existing "Internets" are the same as those in having the Internet grow to
encompass a large number of administrative domains, except for the added
problem of address overlap (which is probably NOT the worst problem).

In terms of address overlap, the solution depends upon whether you use the
DoD IP or the ISO IP.  With the DoD IP, I am not aware of any work on how
to map between two overlapping inconsistent address sets.  The obvious
choice would be to more or less hand-configure some sort of translation,
and have big tables in the gateways on the boundary.  Exactly how this is
done may depend on whether you run out of network numbers for any
particular class of network address.  For example, if a class A address on
one side maps to a class B address on the other, then the host part of the
address would also have to change.  All of this seems potentially ugly.
The ISO protocol, on the other hand, comes complete with globally unique
addresses.  For example, consider the proposed ways in which addressing
could be done with the ISO IP in the DoD Internet (see RFC986, IDEA003, and
a revision of both which is about to come out as a new RFC).  Here the
first three octets of the address specify "DoD Internet", and addresses are
globally unique even with respect to Internets in some other part of the
world.

Another potentially more serious question regards how to route in a future
world of multiple "Internets" (or a multi-domain Internet).  It can be
assumed that most of the administrative domains in the world will have
strict restrictions on what sort of traffic they are willing to carry for
what users.  For example, a particular domain may be willing to carry any
traffic which is strictly internal, traffic between this domain and
neighbors only for specific users and/or applications, and transit traffic
only for a small number of outside domains and specified applications.  The
domain may be very willing to carry electronic mail traffic for their main
competitor, because they want to make copies for themselves (the main
competitor may, for the same reason, be unwilling to use this service).

One can easily envision all sorts of other "policy constraints" affecting
routing.  Thus routing will need to look at all sorts of administrative and
policy considerations.  The IETF Open Routing working group is currently
thinking about how one may do this.  IDEA003 represents a first draft of
the requirements for inter-AS (or Inter-domain) routing, but is only in
draft form (there is a list of proposed updates to be made in the future).
We are currently working on several proposals for how to actually do
routing in this environment.  The Autonomous Networks Task Force is also
working on related issues.

There are other issues that are likely to come up when multiple "Internets"
are interconnected.  For example, there may be a need for congestion
control to be sensitive to administrative policies and contractural
arrangements.  

Ross

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 20:30:24 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   Re: LOOPBACK Net Number

RFC 1009 defines the standard loopback address as {127,any} for
the {net,host} pair.
-------

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 22:21:24 GMT
From:      jerry@oliveb.olivetti.com (Jerry Aguirre)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   Re: Need info on Ethernet products for the IBM AT and Sun

In article <21681@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes:
>At present I do not believe PC-NFS works with the WD interface. I am
>using it with a (brain-damaged) 3Com interface. 

I have version 3.0 of PC-NFS and it lists the following configuration
options for the ethernet adapter:
	
	3Com 3C501, 3C503, 3C505, 3C523

	Ungermann-Bass NIC, NIU

	Western Digital WD8003E

	Micom-Interlan NI5010

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 22:34:25 GMT
From:      garcia@TSCA.ISTC.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   Advance Program SIGCOMM 88 Symposium

All,

Enclosed is the advance program and registration form for the 1988 ACM
SIGCOMM symposium.  SIGCOMM is THE ACM symposium on computer
communications.  This year we have a very strong technical program,
consisting of three days of conference papers, plus one tutorial day.

For more information about hotels and on-campus accommodations, please
contact Stanford University directly (415/723-3126).
Please note that VERY limited on-campus accommodations are available.

To expedite the registration process, you can send print outs of the
attached forms with payment.

Sincerely,

JJ Garcia-Luna
General Chair, SIGCOMM 88

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

			    ACM SIGCOMM 88 SYMPOSIUM
 			        ADVANCE PROGRAM
		 Communications Architectures and Protocols
			      August 16-19, 1988
		  Stanford University, Stanford, California


				  SYMPOSIUM
			      August 17-19, 1988


				August 17, 1988

9:00 - 10:00
Session 1: Keynote Session
	General Chair: J.J. Garcia-Luna-Aceves, SRI International, USA
	Program Chair: L. Landweber, University of Wisconsin, USA
	Student Paper Award: J.J. Garcia-Luna-Aceves, SRI International, USA 
	Keynote Address: Donald Nielson, SRI International, USA

10:30 - 12:00
Session 2: Local/Metropolitan Area Internets 
Chair: D. Anderson, Unviversity of California, Berkeley, USA

     Topological Analysis of Local-Area Internetworks
     (G. Trewitt, Stanford University) --- Student Paper
     Dynamic Resource Allocation in a Metropolitan Area Network
     (K. Maly, C. Overstreet, Old Dominion Univ.; 
     X. Qui, China State Shipbuilding Corporation, Peoples Republic
     of China; and D. Tang, Chengdu University of Science &
     Technology, Peoples Republic of China)
     Optical Interconnection Using ShuffleNet Multihop Networks in
     Multi-Connected Ring Topologies  
     (M.J. Karol, AT&T Bell Laboratories, USA)

1:15 - 2:45
Session 3: Routing 
Chair: L. Chapin, Data General Corporation, USA

    Landmark Routing:  Distributed Name-Based Routing for Very 
    Large Networks 
    (P.F. Tsuchiya, Mitre, USA)
    Pitfalls of a Certain Class of Distributed Routing Algorithms	
    (R. Perlman and G. Varghese, DEC, USA)
    Multicast Routing in Internetworks and Extended LANs
    (S.E. Deering, Stanford University, USA) --- Student Paper

3:15 - 5:15
Session 4: Transport Level and Operating System Issues 
Chair: S. Lam, University of Texas at Austin, USA

     Design of an x-Kernel 
     (N. Hutchinson and L. Peterson, Univ. of Arizona, USA)
     Exploiting Recursion to Simplify RPC Communication Architectures
     (D.R. Cheriton, Stanford University, USA)
     Service Specification and Protocol Construction for the Transport Layer 
     (S.L. Murphy and A.U. Shankar, Univ. of Maryland at College Park, USA)
     A Network Management Language for OSI Networks
     (U. Warrier, A. Relan, Unisys Corporation, USA; 
     O. Berry, IBM Science and Technology, Israel; 
     and J. Bannister, The Aerospace Corporation, USA)

7:00 pm - on
Banquet


				August 18, 1988

8:30 - 10:00
Session 5: Lessons of the Internet 
Chair: J. Mogul, Digital Equipment Corporation, USA

    Some thoughts on the DARPA Internet Architecture 
    (David Clark, MIT, USA)
    The Fuzzball 
    (D.L. Mills, University of Delaware, USA)
    Development of the Domain Name System 
    (Paul Mockapetris, USC Information Sciences Institute, USA)

10:30 - 12:00
Session 6: Local Area Network Architecture 
Chair: R. Cheung, Hewlett-Packard, USA

     Optimizing Bulk Data Transfer Performance: The Packet Train Model
     (C. Song and L.H. Landweber, University of Wisconsin, USA)
     --- Student paper
     A Mesh/Token Ring Hybrid-Architecture LAN 
     (C. Kang, The American University, USA;
     and J. Herzog, Oregon State University, USA)
     Tree LANs with Collision Avoidance: Protocol, Switch Architecture,
     and Simulated Performance
     (T. Suda, S. Morris, and T. Nguyen, 
     University of California, Irvine, USA)

1:15 - 2:45
Session 7: Very High Speed Networking 
Chair: D. Farber, University of Pennsylvania, USA

    An Analysis of Memnet - An Experiment in High Speed Memory Mapped
    Local Networking (G. Delp, A. Sethi, University of Delaware, USA;
    and D. Farber, University of Pennsylvania, USA)
    --- Student paper
    The VMP Network Adapter Board (NAB): High-Performance Network
    Communication for Multiprocessors 
    (H. Kanakia and D. Cheriton, Stanford University, USA) --- Student paper
    Fast Circuit Switching in Fiber Optic Networks
    (I. Chlamtac, A. Ganz, and G. Karmi, University of Massachusetts, USA)

3:15 - 5:15
Session 8. Measurement and Management 
Chair: V. Cerf, Corporation for National Research Initiatives, USA

     A Pseudo-Machine for Packet Monitoring and Statistics
     (R.T. Braden,  USC Information Sciences Institute, USA)
     Knowledge-Based Monitoring and Control: An Approach to
     Understanding the Behavior of TCP/IP Network Protocols
     (B.L. Hitson, Stanford University, USA) --- Student paper
     Measured Capacity of an Ethernet
     (D.R. Boggs, J.C. Mogul, and C.A. Kent, DEC, USA)
     Distributed Testing and Measurement across the Atlantic Packet
     Satellite Network (SATNET)
     (K. Seo, BBN, USA; J. Crowcroft, UCL, England; 
     P. Spilling, Norwegian Telecommunications Administration, Norway;
     J. Laws, Royal Signals and Radar Establishment, Englanand;
     and  C. Topolcic, BBN, USA)

5:30 - 7:00
Reception

				August 19, 1988

8:30 - 10:00
Session 9: Communication Protocol Design and Testing 
Chair: D. Mills, University of Delaware, USA

    A Multicast Transport Protocol 
    (J. Crowcroft and K. Paliwoda, University College London, England)
    Experience with Test Generation for Real Protocols
    (D. Sidhu and T. Leung, Iowa State University, USA)
    Performance Models for Noahnet
    (G.M. Parulkar, A.S. Sethi, D.J. Farber, University of Pennsylvania, USA)

10:30 - 12:00
Session 10: Broadcast Issues 
Chair: D. Sidhu, Iowa State University, USA

     A High Performance Broadcast File Transfer Protocol
     (J.S.J. Daka, A.G. Waters, University of Essex, England)
     Specification and Verification of Collision-Free Broadcast Networks 
     (P. Jain and S.S. Lam, University of Texas, Austin, USA)-- Student Paper
     Delivery and Discrimination: The Seine Protocol
     (M. Gouda, University of Texas at Austin, USA;
     N. Maxemchuk, U. Mukherji, and K. Sabnani,
     AT&T Bell Laboratories, USA)

1:15 - 2:45
Session 11: Congestion and Topology Control 
Chair: J.J. Garcia-Luna-Aceves, SRI International

     An Explicit Binary Feedback Scheme for Congestion Avoidance in
     Computer Networks with a Connectionless Network Layer
     (K.K. Ramakrishnan and  R. Jain, DEC, USA)
     Congestion Avoidance and Control 
     (Van Jacobson, Lawrence Berkeley Laboratory, USA)
     A Protocol to Maintain a Minimum Spanning Tree in a Dynamic Topology
     (C. Cheng, I. Cimet, P. Kumar, Northwestern Univ., USA)


3:00 - 5:00
Session 12: Panel on Internet Engineering
Chair: P. Gross, Mitre, USA
Panelsists to be announced

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



				   TUTORIALS
				August 16, 1988
				9:00 am - 5:00 pm

	            1. INTEGRATED SERVICES DATA NETWORKS:
			  NARROWBAND AND BROADBAND
			      (Mario Gerla, UCLA)


				   Abstract

ISDN is one of the newest " buzzwords " in the communications arena.
The concept is extremely appealing: by integrating various services (
voice, data, video etc.) in a common network we will be able to achieve
lower operating costs, higher efficiency, better
availability/maintainability and higher flexibility in the introduction
of new services.This concept is now becoming a reality, and both users
and service providers are taking into account the potential of ISDN's
in formulating their plans.

This seminar will review the evolution of the ISDN concept during the
past few years,will discuss the standard recommendations, will compare
implemen- tation alernatives and finally will report on recent field
trials.  In organizing this seminar , the attempt was to maintain a
good balance between design principles, standard recommendations and
actual network implementations.


		                Outline

	- Why integrated services
	- Narrowband and Broadband ISDN's
	- Standard recommendations
	- ISDN backbone implementation alternatives
	   ( Packet/Circuit/Hybrid switching)
	- ISDN routing and flow control
	- Service integration in MAN's and LAN's
	- Field trials
	- Future trends

                              Biography

Professor Mario Gerla received the PhD degree in engineering from the
University of California, Los Angeles (UCLA), in 1973.  From 1973 to
1976, he was Network Planning Manager at Network Analysis Corporation.
From 1976 to 1977, he was with Tran Telecommunications, Los Angeles,
where he participated in the development of integrated packet and
circuit networks.  In 1977, he joined UCLA and is now a Professor in
the Department of Computer Science.  His research interests include the
design and control of distributed computer communications systems and
networks, and the development of high-speed local area networks.
 

   		2. MULTI-HOP TOPOLOGIES, BRIDGES AND ROUTERS
			   (Radia Perlman, DEC)

			         Abstract

A Local Area Network (LAN) allows direct communication between any
stations directly connected to the LAN.  Route computation and
forwarding nodes are not necessary.  However, technology and
performance constrains the topology, distance, and number of stations
of a single LAN.  Thus a network usually needs to grow beyond the
limits of a single LAN.  One method of interconnecting LANs is through
"Bridges".  Two different schemes for interconnecting LANs are being
standardized by two different subcommittees of the IEEE 802 committee,
which is standardizing LANs.  These two schemes are "spanning
tree/transparent" bridges, and "source routing" bridges.  Another
method of creating a network with multiple links is through "routers".
These too are being standardized by various committees.  "Routers"
perform the "Network Layer Protocol" as defined by the ISO reference
model.

This tutorial will briefly review the ISO reference model.  It will
explain the two bridge schemes, and contrast their functionality and
performance.  It will explain the functionality of the Network Layer,
and explain design alternatives for meeting this functionality.  The
emphasis will be placed on the design of a "connectionless" style of
Network Layer.  No background other than intellectual curiosity is
required.  Emphasis is on protocol concepts rather than specifics of
the schemes, or mathematical analysis.

                               Outline

     o   ISO Reference Model Review (20 minutes)
     o   LAN review -- CSMA/CD, token ring, token bus (15 minutes)
     o   Bridges -- Spanning Tree, Source Routing, Comparisons (1 1/2
         hours)
     o   Network Layer functionality -- connection oriented vs
         connectionless, routing, fragmentation and reassembly,
         autoconfigurability, addressing (45 minutes)
     o   Routing Algorithms -- "Distance Vector" vs "Link State" (2
         hours)
     o   Depending on time and interest, remaining time can be spent
         exploring the design implications of:
         -   interoperability of spanning tree and source routing
             bridges
         -   Network Layer autoconfigurability
         -   Design implications of hierarchical networks; subnetwork
             partition problem, subnetwork autonomy

                              Biography

Radia Perlman is a consulting engineer at Digital Equipment
Corporation.  She designed the spanning tree algorithm used by
Digital's bridges and adopted for use by both bridge standards
(transparent bridges and source routing bridges).  She also was
responsible for the design and specification of the Network Layer in
Digital's Network Architecture, aspects of which have been adopted by
ISO for use in the standard connectionless Network Layer.

She has taught as adjunct faculty at the graduate schools of Wang
Institute and University of Lowell, and at the Wang Summer Institute.
She received the B.S.  and M.S.  degrees in mathematics at MIT, and is
currently pursuing a Ph.D.  degree in Computer Science at MIT. 


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

                        TUTORIAL AND SYMPOSIUM REGISTRATION


Please check applicable fees:


					ADVANCE			REGULAR
				     (before 7/25/88)

	TUTORIAL 1:
____	ACM members			$200			$250
____	Non-members			 250			 300
____	Full-time students**		 100 			 150

	TUTORIAL 2:
____	ACM members			$200			$250
____	Non-members			 250			 300
____	Full-time students**		 100 			 150

	SYMPOSIUM*:
____	ACM members			$200			$250
____	Non-members			 250			 300
____	Full-time students**		 100			 150


* Reception and banquet fees will be included in the recidence hall
  registration package.

** Student registration must be accompanied by a copy of valid full-time
   student ID. Must be ACM member.

TOTAL PAYMENT MUST BE INCLUDED IN US$.  $____________.

Advance registration payment must be received by July 25, 1988.  After
that date, please wait to register at the Symposium itself.  Make
checks payable in US$ to ACM SIGCOMM.  There will be a $10.00 Surcharge
on foreign banks.

Please return tutorial and symposium registration form and complete
payment to: Dr.  J.J.  Garcia-Luna-Aceves, SRI International, 333
Ravenswood Ave., Menlo Park, CA 94025, USA; tel: (415) 859-5647;
e-mail: garcia@sri.com.


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

	                   APPLICATION FOR RESIDENCE HALLS


Room and meal payments are due upon arrival.  DO NOT PAY IN ADVANCE.
All payments must be in $US dollars, and made in cash, traveler's
checks, or personal checks from a U.S. Bank  made payable to
Stanford University.

A VERY LIMITED number of rooms in Stanford University are available on
a first-come, first-served basis.  Complete this form and return it, no
later than July 25, 1988, to Dr. J.J. Garcia-Luna-Aceves, SRI International, 
Menlo Park, CA 94035; Tel: (415) 859-5647; e-mail: garcia@sri.com.


RATES:

PLAN I - Room for 4 nights (Mon., Tue., Wed., and Thurs.) and 10 meals
from Tue. breakfast thru Fri. lunch (omitting Wed. Dinner).

	Single room - $102.00,    shared room - $76.00
	      meals     95.00           meals - $95.50
		       -------			-------
		      $197.50                  $171.50 per person


PLAN II - Room for 3 nights (Tues., Wed., Thurs.) and 7 meals
(breakfast and lunch on Wed., Thurs., Fri., and dinner on Thursday.

	Single room -  $76.50,    shared room - $57.00
	      meals     65.00           meals - $65.50
		       -------			-------
		      $141.50                  $122.50 per person

EXTRA NIGHT'S STAY: single room - $25.50, shared room - $19.00 per person.

CHILDREN: 10 yrs.  old and under are charged half rate for housing and
meal package. 


RESIDENCE HALL REQUIREMENTS:

Name: ____________________________________________________________
	Last				First		Middle

Address: _________________________________________________________
	 _________________________________________________________
	 _________________________________________________________

____ Plan I,  ____ Plan II
____ Single,  ____ Double
____ Female,  ____ Male
____ Smoking, ____ Nonsmoking

Preferred rommate: ________________________________________________
Date and time of arrival: _________________________________________
Date and time of departure: _______________________________________


_________________________________________________________________________

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 22:44:35 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP (was Re: Dumb vs. smart host routing)

> I suppose I should give Phil Karn a chance to say this first, but
> AMPRnet (Amateur Packet Radio, network 44) generally won't - hidden
> terminal problems and unreliable broadcast performance make it impractical.

My code, written specifically for AMPRNET, does use ARP. We even have
our very own officially registered "hardware type" -- see the Assigned
Numbers RFC.

ARP on amateur packet radio works exactly like it does on Ethernet. Lost
ARP requests aren't a problem, since there'll be a retransmission (from
TCP or whatever) that simply gets turned into another ARP request. There
being no formal broadcast address in the AX.25 link layer protocol,
however, we had to define our own -- "QST". (You hams out there will
understand the significance of these letters :-)).

The only complication comes when "digipeaters" are used. These are
simple store-and-forward repeaters that use a source routing feature in
the link protocol.  Broadcasting through digipeaters doesn't work, so
you have to manually enter the proper source route and destination
address into your ARP table.

Phil

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      20 May 88 22:49:10 GMT
From:      mbeast@attcan.UUCP (Michael East)
To:        comp.protocols.tcp-ip
Subject:   3B2/500 Enhanced TCP/IP on 3.1.1

Help! Has anyone installed Enhanced TCP/IP WIN/3B on a 3B2/anything running
UNIX* 3.1.1? I am perplexed and confused and have been unable to install it
sucessfully. I seem to be missing the board drivers or something to
interface to the hardware.

Any help would be greatly appreciated (by e-mail please).

Thanks in advance,
-----
Michael B. East (mbeast)		AT&T Canada Inc., Toronto
{utzoo,uunet}!attcan!mbeast		(416) 756-5099

There is no time like the present for postponing what you ought to be doing.

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      21 May 88 00:14:33 GMT
From:      dricej@drilex.UUCP (Craig Jackson)
To:        comp.protocols.tcp-ip,comp.sys.pyramid
Subject:   Slip on pyramid?

Is there a slip driver for a Pyramid?  Would the slip driver in
the sun-spots archives (which claims to work for a 4.2 VAX, too)
work on a pyramid?  I'm assuming there may be some minor editing,
but could you get it to work?  This is for a binary-only site.

I would be interested in corresponding with anybody who has gotten
this to work.
-- 
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX:  cjackson

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      21 May 88 01:45:29 GMT
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   Re: Need info on Ethernet products for the IBM AT and Sun

In article <22166@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes:
.In article <21681@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes:
..At present I do not believe PC-NFS works with the WD interface. I am
..using it with a (brain-damaged) 3Com interface. 
.
.I have version 3.0 of PC-NFS and it lists the following configuration
.options for the ethernet adapter:
.	
.	Western Digital WD8003E

What an idiot I am! You are absolutely right, it does list it as supported.
Time to throw out my 3Com and buy a WD!
-- 
Make Japan the 51st state!

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      21 May 88 05:00:46 GMT
From:      satz@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   (none)

Kevin,

Someone was supposed to write up an RFC describing the mapping used for
class B and C addresses. What is currently being used in the cisco DDN X.25
implementation is:

	class A: N.H.L.I
	class B: N.N.H.I
	class C: N.N.N.HI

Where N represents the network number. H represents the PSN port number. L
is the logical host field and is still zero. I is the PSN number. For class
B addresses, the H field uses the unused L field.  For class C addresses,
the H field lies in the upper four bits of the last octet and the I field
in the lower four. I don't know of anyone who has a class C PSN network.

Hope this helps,

Greg Satz
cisco

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      21 May 88 15:33:57 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  HYROUTE(TCP/IP gateway between HYPERchannel and ethernet)

If you don't use hyroute, then the hyperchannel driver will demand
an IP address of the form

	<anything>.<loopback_code>.<adapter_address>.<port_number>

(with each <xxx> an 8-bit field) and then you really do need a class A net.

But if you use hyroute, you can just put "direct" statements into
/etc/hyroute.conf and create an arbitrary mapping of
IP addresses to (loopback_code, adapter_addr, port_number, other_bits) tuples.

In other words, you can use any IP addresses you wish -- they should
fit just fine into a subnetted class B network.

Since Crays don't do subnetting yet (in 3.0 at least, I think not in 4.0
either) you may have to use another machine as a subnet gateway, but that
shouldn't be too troublesome.

I know the above is true for the Cray-2 since we're actually using
hyroute in this way.  I'm reasonably certain that X-MP's act the same way.

	Stuart Levy, Minnesota Supercomputer Center
	slevy@uc.msc.umn.edu, (612) 626-0211

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 May 88 20:54:56 EDT
From:      craig@harvard.harvard.edu
To:        tcp-ip@sri-nic.arpa
Subject:   papers on session and presentation layers

Anyone know of any good papers on either the session or presentations
layers?

Thanks,

Craig

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      21 May 88 20:36:22 GMT
From:      MURAKAMI@ntt-20.ntt.jp (ken-ichiro murakami)
To:        comp.protocols.tcp-ip
Subject:   HYROUTE(TCP/IP gateway between HYPERchannel and ethernet)

I have some questions about address mapping between HYPERchannel and IP
address. Please let me know if you know HYROUTE mapping mechanism.

  We are using HYROUTE on SUN to connect hosts on HYPERchannel and hosts
on ethernet by TCP/IP.  We used class A IP address on Hyperchannel and
class C IP address on ethernet so far. We did not obtained the class A
address from SRI-NIC. This is because these hosts are isolated from
our main network. Recently, we decided to connect the HYPER channel
network to our main network and change the address from class A to
subnetted class B which we obtained from SRI-NIC. When I asked our
support engineer to change it, he told me that it was impossible to
use subnetted class B address on HYPERchannel. I heard the problem was
caused by HYROUTE address mapping facility. 

  Since I could not find HYROUTE documents around me, I estimated the
mapping from /etc/hosts, /etc/networks and /etc/hycf files. It seems
there is no dynamic mapping between HYPERchannel address and IP
address. Static mapping is employed. In addition to it, the mapping is
so simple and HYPERchannel address(8bit physical address + 8bit
logical address) is used as the lower 2 byte of IP address. It
consumes a lot of IP address. Our network address is class B and we
cannot afford to assign a lot of subnet and host address to
HYPERchannel. So, I'd like to ask you the following questions;


(1) Is there any way to save IP address on HYPERchannel?
(2) Why does HYROUTE need class A address on HYPERchannel?
(3) Where are the documents for HYROUTE and its mapping algorithm?
    Is it possible to get it?


Thanks in advance.

					KEN
			murakami%ntt-20.ntt.jp@relay.cs.net

	Ken-ichiro Murakami
	NTT Laboratories
	3-9-11, Midori-cho, Musashino-shi
	Tokyo, 180 Japan

-------

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      22 May 88 04:01:02 GMT
From:      mmm!brad@ucbvax.Berkeley.EDU (Brad Rhoades)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.dcom.lans,comp.unix.questions,comp.unix.wizards
Subject:   Ethernet packet type information requested.

	I am interested if anyone can send me a copy of the specifications
	or listings of the cross-reference for ethernet type's in numeric
	form to the actual verbal description.  The Netwatch software
	that displays the type of packets in numeric form for all packets
	and lists the names of those it knows of, but doesn't tell what
	all the packets are.  Any info on how to obtain this would also 
	be helpful.
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      22 May 88 06:08:00 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   Gateway to Net Ten

GATEWAY TO NET TEN    -- Mark Lottor

[Original words and music by Jimmy Page and Robert Plant]

There's a hacker who's sure all that's coax is fast
and he's buying a gateway to net ten.
When he gets it he'll know if the ports are all closed
with a SYN he can get what he sent for.

Ooh ooh ooh ooh, ooh ooh ooh ooh
and he's buying a gateway to net ten.

There's an RFC on the wall but he wants to be sure
cause you know sometimes words have two meanings.
In a note on the page there's a warning that says
sometimes all of our code is broken.

Don't ya know, it makes me wonder.

There's an error I get when I send to the net
and my packets are lost and retransmitting.
In my logs I have seen loops of mail thru the machine,
and the screams of those who are hacking.

Oooh, it makes me wonder.

And it's whispered that soon if we all fix and tune
then the packets will reach their destinations.
And a new day will dawn for hosts that stay long
and the telnets will echo quite faster.
 
Ohhhhh, it makes me wonder.

If there's a bustle in your cisco, don't be alarmed now
it's just a quick ping for the NIC machine.
Yes there are two paths you can route by, but in the long haul
there's still time to change the protocol.
	
Yowwww, it makes me wonder.

Your host is loaded and it will slow in case you don't know,
the unix's are asking you to join them.
Dear hacker, do you see the overflow, and did you know
your gateway is still under development.

And as we wind out more coax, and gateways slower than our hosts,
There goes a message we all know, it updates routes and wants to show
how everything still turns quite slow.
And if you listen very hard, the bits will come to you at last.
When all are ones and ones are all, to be a rubout and not a null.

And he's buying a gateway to net ten...
-------

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      22 May 88 09:01:38 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Transport Level Interface

In article <349@manta.NOSC.MIL> gutman@manta.NOSC.MIL (Lewis M. Gutman) writes:
>A month or two ago I read something about the Transport Level
>Interface, being developed, I believe, at Bell Labs.  My 
>understanding was that it offered a standard interface to 
>tcp.  Can anyone shed any light on TLI?  Can anyone suggest
>a reference?  If TLI is not a software interface to tcp, can
>anyone tell me whether there is such a thing?  Reply directly,
>please.  

TLI is included in System V.3 from AT&T.  It is a library interface for network
transport services that is *very* similar to Berkeley sockets.  It is thus not
an interface to TCP specifically, but to any transport service.  It is both
very slightly better and very slightly worse than sockets.  Sun has committed
to supporting TLI as a part of its deal with AT&T for System V.4.  I don't
think anyone interprets this to mean that SunOS sockets will go away, however.
TLI is often linked with Streams, since they were introduced at the same time
and both deal with networking, but they are actually independent of each other.

I like the SVID, Issue 2, Volume 3 presentation of TLI better than the one in
the AT&T UNIX System V Network Programmer's Guide, myself.  One of the X/Open
books may refer to it as well; I don't remember for sure.

-bc
-- 
Bill Crews                   Tandem Computers        bc@halley.UUCP
(512) 244-8350               Austin, Texas           ..!rutgers!im4u!halley!bc

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      22 May 88 15:25:27 GMT
From:      donegan@stanton.TCC.COM (Steven P. Donegan)
To:        comp.protocols.tcp-ip
Subject:   Re: connecting Internets?


I hope this isn't a hopelessly stupid question but:

In the network I am attempting to build at my employer's site(s) we have a class
B primary address 129.253.x.x and many workstations from many diverse vendors.
The network backbone spans many buildings and countries via MAC level bridges.
Most of the TCP/IP devices (our network is primarily XNS and DECNET) are of the
SUN persuasion, one server with both MAU and thinwire interfaces, the thinwire
running to 5 or 6 workstations and the MAU connecting to the backbone. The
problem I have run into on a continuous basis is the situation where, even
though the packets are capable of being seen by all parties, a host rejects a
connection because (I think) the destination/source pair are in a different
'subnet' ie 129.253.001.x and 129.253.002.x. Is there any way under legal
TCP/IP to get these blasted devices to talk to each other without buying a
hardware device such as a gateway or router? I feel that the 'feature' of
subnetting in my particular network is really a major LIMITATION! I have NONE
of these types of problems with my XNS or DECNET devices. Help. Please, no
flames for stupidity, I've been networking systems for a living for quite a
while and am really interested in learning about this subject.
-- 
Steven P. Donegan
Sr. Telecommunications Analyst
Western Digital Corp.
donegan@stanton.TCC.COM

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      22 May 88 20:22:15 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   (none)

I'll make the official pronouncement blessing the Class B PSN mapping.
This is what BRL uses and this is what we've (DDN) specified for this
wierd thing called a concentrator.  As far as the class C mapping, 
the one cisco uses is as good as any.  I'd recommend you treat this as a
per network split, and set it up so you can use any amount of the bits
to represent host or packet switch.

Mike

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 May 88 09:04:41 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "J. Kevin Rohan" <jjkkrr@FORD-COS1.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   mapping an IP address into an X.25 address
>  NETINFO:X25.DOC ... covers the DDN's class A IP address

The DDN (Milnet, Arpanet) x.25 service is supplied by packet switch nodes
(PSNs') which have the internal structure reflected in the address given to
each host attachment point.  Embedded in the 14 digit address is 3 digits of
PSN and 2 digits of host port connection on that PSN.  Since there is this
known mapping, the number of digits can be encoded uniquely in the 24 bits
of 'host' of a class A IP address.

>  It seems like gateways everywhere support this but where's the algorithm???

The general case of any arbitrary X.25 address for a network in any country
cannot be handled by a single algorithm, so the implementations that I know of
have a separate data base which is typed in to the individual gateway when it
is configured, or perhaps down-loaded from a file provided with the gateway.

Maybe you want to specify an address resolution protocol (ARP) service where
the information is stored in a single central host, instead of the ethernet
style of ARP where the information for each host is stored in the individual
hosts.  You then only have to configure one address in each machine, the
address of the ARP server.  (The address of "the ARP server" on ethernet is
"broadcast".)

Mike Brescia
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 May 88 09:59:24 EDT
From:      Greg Swartwout <R1ECGF%AKRONVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   summation of IBM internet responses


  Sorry this took so long to respond, but things have been rather busy
lately.  Several weeks ago I asked for information, the original message
is included again in case anyone missed it and might be able to help.
If I get any more responses I will post them also.


>  We have just recently started connecting the different system here to
>internet and are innterested in finding out how other sites had handled
>IBM mainframes.  We are particularly interested in knowing what hardware
>and software has been used, and the advantages and disadvantages of each.
>TCP/IP, Ethernet, and DECNET are the main protocol we are interested in.
>Please respond directly to me, as I am not on all of these lists.

  These are most of the responses which I received.

                                 Greg Swartwout

****
From:         Bob Blackmun <ACC00RRB@UNCCVM>

From our reading of comments on various lists, the IBM TCP/IP for VM
software and the IBM 8232 to provide the channel-to-Ethernet
hardware connection seem to be the consensus.
****
From:         Michael Hebgen <$02@DHDURZ1>

Like you  we are just  in the process  of connecting our  IBM mainframes
running VM  and MVS to  Internet via Ethernet-TCP/IP. Because  there are
just a  few offers  for the MVS  site we have  selected the  ACS9310 box
from Synelec,  which runs on  the VM site  with the IBM  TCP/IP software
and on the MVS site with  software provided from Synelec. The ACS-box is
physically  connected to  the VM  machine  (4381) and  we try  to get  a
connection to a MAC  workstation, the box for the MVS  site is on order.
Like you  we are interested in  this survey, especially in  Gateways for
mapping the TCP/IP  applications like SMTP mail  to EARN/BITNET applica-
tions and vice versa. Could you please forward information on this topic
if you receive one.
Thanks and regards, Michael
****
From:         Peter Coleman <PCOLEMAN@MCMVM1>

At McMaster we currently use 2 Bridge CS100's to connect ethernet
to our IBM Hosts.  Mail is transferred via a BSC line from a Vax using
JNET.  We also have a DEC SNA Gateway which only talks to MVS.

We have now signed a contract with IBM for an 8232 and hope to replace
all Vax and Ethernet connections with it. This means that we run the
5798-FAL software in VM.  This set up also provides us with the ability
to let 3270 users connect from VM via ethernet to our Vaxes or using a
gateway CS100 to Datapac and other external services.  We use a 3Com
ethernet and the 8232 will require a 3-Com card to attached to
ethernet.  Our main ethernet uses fibre.

        Peter Coleman
****
From:         Nick Gimbrone <NJG@CornellA>

We find the IBM 5798-FAL (TCP/IP product for VM) to be great. Check
out the comments on the IBMTCP-L@CUNYVM list. The only possible current
problem is the IBM network attachment performance (better than before,
but still not up to what you can do with 3rd party vendor hardware).
However, there are drivers for the 3rd party vendor hardware, so it
really is great stuff. :-)
****
From: nowicki@Sun.COM (Bill Nowicki)

Sun sells a product called CA3270 that allows a Sun to attach to an
IBM Channel.  We use these to talk to our mainframes, since of course
we trust our own TCP and DECnet software.  That is, you plug one of these
into a 3/150 or 3/180, 4/280, etc. and replicate depending on load.
Then run the TCP and DECnet on the Sun to act as a front end - Sun cycles
are much chaper than 3090 cycles.

    -- WIN
****
From: mqh@crnlthry.BITNET (Mike Hojnowski)

For our VM systems, we use IBMs TCP/IP Program Offering (5798-FAL).
There is a mailing list for that product (IBMTCP-L@CUNYVM.CUNY.EDU).
If you would like more information, feel free to contact me.

Mike Hojnowski
Network System Programmer
Cornell University
****
From: ames!pacbell!belltec!lance@ucbvax.berkeley.edu
Return-Path: <ames!pacbell!belltec!lance>

An ex-coworker of mine has ported Berkeley 4.3 TCP to Amdahl UNIX 5.2.
He is Rob Warnock in San Mateo, California.
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      05/23/88 11:09:38
From:      Keith R. Hacke <M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   DECnet-Internet Gateway
Does anyone have experience with DEC's DECnet-ULTRIX V2.0 product. I
understand it acts as a bidirectional DECnet-Internet gateway. I.E., it
supports DECnet and Internet commands for file transfer, remote login, and
mail.

I have a document from DEC that show examples of using this product. It
"translates" VMS commands into TCP/IP!?

This is very interesting to me because I have a very large community of VMS
users who wish to use the services of the DDN. But they have no TCP/IP
experience. Nor do I wish them to have to buy and learn TCP/IP applications
(SMTP, FTP, TELNET).I need away to route VMSmail and All-In-One mail onto the
DDN, an receive DDN mail back into these DEC mail systems.

If you have experience with DECnet-ULTRIX V2.0 (or later?) I would like to
hear about it. Does it really allow VMS users to access services on the DDN and
vice-versa?

I will summarize and re-post, if response/interest in sufficient.

Keith R. Hacke
McDonnell Douglas - MCAIR Telecommunications
314-895-5343

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 14:20:00 PST
From:      <art@acc.arpa>
To:        "jjkkrr" <jjkkrr@ford-cos1.arpa>
Cc:        tcp-ip@sri-nic.arpa
Subject:   more DDN X.25

>Someone was supposed to write up an RFC describing the mapping used for
>class B and C addresses. What is currently being used in the cisco DDN X.25
>implementation is:
>
>	class A: N.H.L.I
>	class B: N.N.H.I
>	class C: N.N.N.HI
>
>Where N represents the network number. H represents the PSN port number. L
>is the logical host field and is still zero.  I is the PSN number. For class
>B addresses, the H field uses the unused L field.

There are people out there using the logical host field on Class A nets.

>For class C addresses,
>the H field lies in the upper four bits of the last octet and the I field
>in the lower four.

We use pretty much the same algorithm in ACC devices except that we tend to
us a 3 bit IMP number and 5 bit Port number split (since IMPs can support
more than 16 hosts).

> I don't know of anyone who has a class C PSN network.

Unless BBN has done it, we probably are the closest.  We actually have a
Class C number that was assigned for use by our test IMP, but we have never
really used it.

						Art Berggreen
						art@acc.arpa

------
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 08:25:10 GMT
From:      csg@pyramid.pyramid.com (Carl S. Gutekunst)
To:        comp.protocols.tcp-ip,comp.sys.pyramid
Subject:   Re: Slip on pyramid?

In article <569@drilex.UUCP> dricej@drilex.UUCP (Craig Jackson) writes:
>Is there a slip driver for a Pyramid?

It's part of the NSP option to OSx 4.4. Talk to your salescritter. If you
already have Ethernet, and you upgrade to OSx 4.4, you'll get SLIP, no extra
charge.

>Would the slip driver in the sun-spots archives (which claims to work for
>a 4.2 VAX, too) work on a pyramid?

Nope. The OSx networking isn't 4.2BSD, it's 4.3. Also, if you have a multi-
processor system, you have this little problem of semaphores to deal with....

<csg>

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 11:49:09 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet packet type information requested.

From URBANIAK@G.BBN.COM Thu Feb  5 22:10:55 1987
Received: from ORNL-MSR.ARPA by icarus.ARPA (3.2/4.9)
	id AA02041; Thu, 5 Feb 87 22:10:52 EST
Received: by ORNL-MSR.ARPA (5.51/4.9)
	id AA17670; Thu, 5 Feb 87 22:07:19 EST
Date: 5 Feb 1987 18:21-EST
Sender: URBANIAK@G.BBN.COM
Subject: Re: seeking source for Ether packet types and vendor address...
From: Urbaniak@G.BBN.COM
To: dunigan@ORNL-MSR.ARPA, tcp-ip@SRI-NIC.ARPA
Cc: Urbaniak@G.BBN.COM, rtavilla@RCCA.BBN.COM
Message-Id: <[G.BBN.COM] 5-Feb-87 18:21:17.URBANIAK>
In-Reply-To: <[G.BBN.COM]27-Jan-87 17:24:31.URBANIAK>
Status: R

This list of Ethernet vendor addresses and Type Fields includes responses
of the last week.

 Current BBN Ethernet and IEEE802.3 "Type" Fields

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These are formerly assigned by
Xerox, currently assigned by IEEE. Some assignments are public, others private.
Information currently available includes: Xerox Public Ethernet Packet
Type documentation; IEEE802.3 Std, but not yet further documentation from
IEEE; NIC RFC960; knowledge of some BBN Private Type Field values.

Hex
0000-05EE	IEEE802.3 Length Field
0600	Xerox NS IDP *
0800	DOD IP * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	ARP * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine protocol? *
5208	BBN Simnet Private
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC LAT
6005	DEC protocol, at interface initialization?
6006	DEC user protocol
6007	DEC cluster protocol
7001	UB NIU
7002	UB NIU
7030	Proteon
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8035	Reverse ARP
8038	DEC LanBridge Management
803f	DEC LanBridge Management
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
809B	AppleTalk over Ethernet (Kinetics only?)
80f3	MacEther
9000	Loopback (Configuration Test Protocol)
9001	Bridge bridge
9003	Bridge server?
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.
 Ethernet Vendor Addresses

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.

Currently we have noted the following vendor addresses, on the
BBN Corporate Ethernet.

000093	Proteon
0000AA	Xerox		Xerox machines
0000C0	Gould
000102	BBN		BBN internal usage (not registered)
00DD00	Ungermann-Bass	RT
020701	Interlan	UNIBUS or QBUS machines, Proteon
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp,palantir
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp, Sil. Gra.
08001A	Data General
08001E	Apollo
080020	Sun		Sun machines
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080041	DCA
080047	Sequent
08004C	Encore
08005a  IBM  9370
080068	Ridge
080086	Imagen
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Physical address for some DEC machines
AA0004	DEC		Logical address for systems running DECNET

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), I am unaware of the algorithm.
 Current BBN Ethernet Multicast Addresses

I do not have protocol specifications for DECNET and the VALID
protocol at this time.
There is no XNS or VALID router at present; those packets might be
Hello packets, or gateway query packets.

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				lowest-addressed LanBridge
09-00-2B-01-00-0F	6004	DEC LAT 1/15s
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-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-FF-FF-FF
AB-00-04-01-4D-02	6007	DECNET diskserver hello 1/5s
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	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 13:04:41 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   mapping an IP address into an X.25 address

>  NETINFO:X25.DOC ... covers the DDN's class A IP address

The DDN (Milnet, Arpanet) x.25 service is supplied by packet switch nodes
(PSNs') which have the internal structure reflected in the address given to
each host attachment point.  Embedded in the 14 digit address is 3 digits of
PSN and 2 digits of host port connection on that PSN.  Since there is this
known mapping, the number of digits can be encoded uniquely in the 24 bits
of 'host' of a class A IP address.

>  It seems like gateways everywhere support this but where's the algorithm???

The general case of any arbitrary X.25 address for a network in any country
cannot be handled by a single algorithm, so the implementations that I know of
have a separate data base which is typed in to the individual gateway when it
is configured, or perhaps down-loaded from a file provided with the gateway.

Maybe you want to specify an address resolution protocol (ARP) service where
the information is stored in a single central host, instead of the ethernet
style of ARP where the information for each host is stored in the individual
hosts.  You then only have to configure one address in each machine, the
address of the ARP server.  (The address of "the ARP server" on ethernet is
"broadcast".)

Mike Brescia

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 13:59:24 GMT
From:      R1ECGF@AKRONVM.BITNET (Greg Swartwout)
To:        comp.protocols.tcp-ip
Subject:   summation of IBM internet responses



  Sorry this took so long to respond, but things have been rather busy
lately.  Several weeks ago I asked for information, the original message
is included again in case anyone missed it and might be able to help.
If I get any more responses I will post them also.


>  We have just recently started connecting the different system here to
>internet and are innterested in finding out how other sites had handled
>IBM mainframes.  We are particularly interested in knowing what hardware
>and software has been used, and the advantages and disadvantages of each.
>TCP/IP, Ethernet, and DECNET are the main protocol we are interested in.
>Please respond directly to me, as I am not on all of these lists.

  These are most of the responses which I received.

                                 Greg Swartwout

****
From:         Bob Blackmun <ACC00RRB@UNCCVM>

From our reading of comments on various lists, the IBM TCP/IP for VM
software and the IBM 8232 to provide the channel-to-Ethernet
hardware connection seem to be the consensus.
****
From:         Michael Hebgen <$02@DHDURZ1>

Like you  we are just  in the process  of connecting our  IBM mainframes
running VM  and MVS to  Internet via Ethernet-TCP/IP. Because  there are
just a  few offers  for the MVS  site we have  selected the  ACS9310 box
from Synelec,  which runs on  the VM site  with the IBM  TCP/IP software
and on the MVS site with  software provided from Synelec. The ACS-box is
physically  connected to  the VM  machine  (4381) and  we try  to get  a
connection to a MAC  workstation, the box for the MVS  site is on order.
Like you  we are interested in  this survey, especially in  Gateways for
mapping the TCP/IP  applications like SMTP mail  to EARN/BITNET applica-
tions and vice versa. Could you please forward information on this topic
if you receive one.
Thanks and regards, Michael
****
From:         Peter Coleman <PCOLEMAN@MCMVM1>

At McMaster we currently use 2 Bridge CS100's to connect ethernet
to our IBM Hosts.  Mail is transferred via a BSC line from a Vax using
JNET.  We also have a DEC SNA Gateway which only talks to MVS.

We have now signed a contract with IBM for an 8232 and hope to replace
all Vax and Ethernet connections with it. This means that we run the
5798-FAL software in VM.  This set up also provides us with the ability
to let 3270 users connect from VM via ethernet to our Vaxes or using a
gateway CS100 to Datapac and other external services.  We use a 3Com
ethernet and the 8232 will require a 3-Com card to attached to
ethernet.  Our main ethernet uses fibre.

        Peter Coleman
****
From:         Nick Gimbrone <NJG@CornellA>

We find the IBM 5798-FAL (TCP/IP product for VM) to be great. Check
out the comments on the IBMTCP-L@CUNYVM list. The only possible current
problem is the IBM network attachment performance (better than before,
but still not up to what you can do with 3rd party vendor hardware).
However, there are drivers for the 3rd party vendor hardware, so it
really is great stuff. :-)
****
From: nowicki@Sun.COM (Bill Nowicki)

Sun sells a product called CA3270 that allows a Sun to attach to an
IBM Channel.  We use these to talk to our mainframes, since of course
we trust our own TCP and DECnet software.  That is, you plug one of these
into a 3/150 or 3/180, 4/280, etc. and replicate depending on load.
Then run the TCP and DECnet on the Sun to act as a front end - Sun cycles
are much chaper than 3090 cycles.

    -- WIN
****
From: mqh@crnlthry.BITNET (Mike Hojnowski)

For our VM systems, we use IBMs TCP/IP Program Offering (5798-FAL).
There is a mailing list for that product (IBMTCP-L@CUNYVM.CUNY.EDU).
If you would like more information, feel free to contact me.

Mike Hojnowski
Network System Programmer
Cornell University
****
From: ames!pacbell!belltec!lance@ucbvax.berkeley.edu
Return-Path: <ames!pacbell!belltec!lance>

An ex-coworker of mine has ported Berkeley 4.3 TCP to Amdahl UNIX 5.2.
He is Rob Warnock in San Mateo, California.

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 14:35:05 GMT
From:      shore@REASON.PSC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: HYROUTE(TCP/IP gateway between HYPERchannel and ethernet)

I'm using class B addresses on a HyperChannel subnet (8 bit subnet
portion) from a uVax running 4.3, but I had to tickle the device
driver some.  The problem was that the driver was using the host part
of the address as a hash key, as was hyroute, but the kernel and
library routines to get it are slightly different (the kernel strips
off subnet bits - the library version doesn't).  This is easily fixed,
but you may be having different problems with the Sun driver.

Melinda

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 15:53:38 GMT
From:      dab@oliver.CRAY.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  HYROUTE(TCP/IP gateway between HYPERchannel and ethernet)


I can proababaly answer quite a few questions about HYROUTE.
First, it depends on what version of HYROUTE you are using.
There have been two main versions of the HYPERchannel driver,
the one written years ago at Tektronix (and distributed with
4.2BSD and 4.3BSD), and the one developed by CRAY research.
The two drivers are incompattable with each other, because
the Tektronix driver uses a variable size Message Proper,
and the CRAY driver insists on a 64 byte Message Proper.
From my experience, a lot of vendors that have HYPERchannel
drivers are using the CRAY version (since there is now an
RFC, #1044, that is compatable with the CRAY version)

HYPERchannel does NOT have a broadcast mechanism.  Therefore,
if you are going to use TCP/IP over HYPERchannel, you can't use
ARP, and you have to have some other method for translating IP
address to HYPERchannel address.

For those that do not use a HYROUTE command, the usual method
is to put the 16 bit HYPERchannel address in the bottom 16 bits
of the IP address.  With that scheme, you can not use subnetted
Class B addresses.  Also, several implementations also use bits
in the 3rd byte for loopback control information, hence meaning
that this scheme only works with Class A addresses.  I personally
find this method as less than acceptable.

The HYROUTE program provides the kernel with mappings between
internet address and HYPERchannel addresses.  Typically, it uses
a hash table to speed up lookups.  HYROUTE should work with
Class A, B and C addresses.  If you machine/driver doesn't work
with all of them, complain to the vendor because the implementation
is broken.

For most implementations of HYROUTE, it does it's hashing, on just
the host part of the address.  I've been thinking long and hard on
this.  It can cause problems with subnets if the HYROUTE program and
the kernel are not in sync with each on whether or not a network is
subnetted.  The HYROUTE builds the hash table and writes it into
the kernel, so the kernel had better be hashing things the same
way as HYROUTE or things won't work right.  I'll probably be
changing the CRAY UNICOS implementation of HYROUTE to hash  on the
entire 32 bit IP address, and then it won't matter any more
whether an address is subnetted or not.

The bottom line is that any implementation of HYROUTE that limits
you to a subset of the IP addresses that the vendor supports is
broken.  (That is, if the vendor doesn't support subnets, then
his HYROUTE program isn't broken because it doesn't work with
subnets.  But if the vendor does support subnets, as the vendor
should, and HYROUTE does not work with subnets, then the vendor's
implementation is broken)

			-Dave Borman
			CRAY Research, INC.

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 16:24:36 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   FTP server question



	[]

	An FTP puzzle for the protocol whizes on the net.  Consider the
	following two sniffer packets from a long trace:

	Packet 1 contains a FTP servers Hello message without a CR/LF.
	Packet 2 contains the CR/LF.

	RFC 959, section 4.2 of the DDN protocol handbook Page 2-773 and 2-774
	clearly state:

	       "A reply is defined to contain the 3 digit code, followed
		by Space <SP>, followed by one line of text (where some
		maximum line length has been specified), and terminated by the
		Telnet end of line code."


	At first glance, the FTP server is at fault.  However, in their
	defense,  FTP uses TCP, a stream oriented protocol, to ensure 
	reliable delivery.  This means that the data from a stream can 
	come out as one single packet, or in the worst case, dribble out
	as a stream of single bytes.  So in the second case, the split of
	the FTP message, and the TELNET CR/LF is not so bad.

	Needless to say, something bad happens on my end as a result; nothing
	that I can't hack around, but before doing so, I thought the problem
	was interesting enough to solicit some other opinions,


						Larry Backman
						Micom - Interlan

 - - - - - - - - - - - - - - - - Frame 63 - - - - - - - - - - - - - - - - -

SUMMRY  Delta T     Destination   Source        Summary
   63    0.0291  02070100B550 080014302203  FTP R PORT=1230 220 MIND FTP server (EXOS Version 4.5 Mon Sep 8 08...

FTP:  ----- FTP data -----
FTP:  
FTP:  220 MIND FTP server (EXOS Version 4.5 Mon Sep 8 08...
FTP:  

ADDR  HEX                                                ASCII
0000  02 07 01 00 B5 50 08 00  14 30 22 03 08 00 45 00  .....P...0"...E.
0010  00 71 66 A9 00 00 3C 06  15 02 80 A6 80 83 80 A6  .qf...<.........
0020  81 0C 00 15 04 CE 03 12  DD C2 00 A1 51 42 50 18  ............QBP.
0030  10 00 16 27 00 00 32 32  30 20 4D 49 4E 44 20 46  ...'..220 MIND F
0040  54 50 20 73 65 72 76 65  72 20 28 45 58 4F 53 20  TP server (EXOS 
0050  56 65 72 73 69 6F 6E 20  34 2E 35 20 4D 6F 6E 20  Version 4.5 Mon 
0060  53 65 70 20 38 20 30 38  3A 34 31 3A 31 37 20 50  Sep 8 08:41:17 P
0070  44 54 20 31 39 38 36 29  20 72 65 61 64 79 2E     DT 1986) ready.



- - - - - - - - - - - - - - - - Frame 64 - - - - - - - - - - - - - - - - -

SUMMRY  Delta T     Destination   Source        Summary
   64    0.0001  02070100B550 080014302203  FTP R PORT=1230 <0D><0A>

FTP:  ----- FTP data -----
FTP:  
FTP:  <0D><0A>
FTP:  

ADDR  HEX                                                ASCII
0000  02 07 01 00 B5 50 08 00  14 30 22 03 08 00 45 00  .....P...0"...E.
0010  00 2A 66 AA 00 00 3C 06  15 48 80 A6 80 83 80 A6  .*f...<..H......
0020  81 0C 00 15 04 CE 03 12  DE 0B 00 A1 51 42 50 18  ............QBP.
0030  10 00 58 00 00 00 0D 0A  30 20 4D 49              ..X.....0 MI

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 16:31:17 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  LOOPBACK Net Number

See RFC-1009, p. 15.

  Bob Braden
  

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 18:09:38 GMT
From:      M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke)
To:        comp.protocols.tcp-ip
Subject:   DECnet-Internet Gateway

Does anyone have experience with DEC's DECnet-ULTRIX V2.0 product. I
understand it acts as a bidirectional DECnet-Internet gateway. I.E., it
supports DECnet and Internet commands for file transfer, remote login, and
mail.

I have a document from DEC that show examples of using this product. It
"translates" VMS commands into TCP/IP!?

This is very interesting to me because I have a very large community of VMS
users who wish to use the services of the DDN. But they have no TCP/IP
experience. Nor do I wish them to have to buy and learn TCP/IP applications
(SMTP, FTP, TELNET).I need away to route VMSmail and All-In-One mail onto the
DDN, an receive DDN mail back into these DEC mail systems.

If you have experience with DECnet-ULTRIX V2.0 (or later?) I would like to
hear about it. Does it really allow VMS users to access services on the DDN and
vice-versa?

I will summarize and re-post, if response/interest in sufficient.

Keith R. Hacke
McDonnell Douglas - MCAIR Telecommunications
314-895-5343

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      23 May 1988 22:21-EDT
From:      CERF@A.ISI.EDU
To:        mcvax!piet@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: toothpaste
At one time, some nameless wag asserted that he thought TCP
stood for Tom Cat Piss because it was such a powerful protocol...

Vint
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 21:07:39 GMT
From:      bzs@bu-cs.BU.EDU (Barry Shein)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: FTP server question


>	An FTP puzzle for the protocol whizes on the net.  Consider the
>	following two sniffer packets from a long trace:
>
>	Packet 1 contains a FTP servers Hello message without a CR/LF.
>	Packet 2 contains the CR/LF.
 ...
>	At first glance, the FTP server is at fault.  However, in their
>	defense,  FTP uses TCP, a stream oriented protocol, to ensure 
>	reliable delivery.  This means that the data from a stream can 
>	come out as one single packet, or in the worst case, dribble out
>	as a stream of single bytes.  So in the second case, the split of
>	the FTP message, and the TELNET CR/LF is not so bad.
 
>						Larry Backman

Unless I misunderstand you there's nothing wrong with the server, it's
not unusual for a system to produce such a message in two (or more)
writes and each end up in its own packet, how is the underlying OS
supposed to know to wait for one more write before shipping the data
from the first write?

(using UDP the server application might indeed have to control such
behavior by buffering its own writes to "packet" boundaries [even
that's only "virtual" packet boundaries, fragmentation could still
show up on the wire, which sounds like what you're measuring, but
should be transparent to the client], but that's not the issue here.)

Your "defense" of the server is correct. Sounds like your client is
imposing record boundaries on a TCP stream where it shouldn't, you
should be able to read until you see CR-LF (or EOF or ERROR) w/o
regard to how the data was sent. Consider it a bug in the client,
possibly at the application level (ie. i bet they're assuming that the
entire record will arrive in one read operation rather than looping
reads until the CR-LF shows up.)

	-Barry Shein, Boston University

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      23 May 88 22:20:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   more DDN X.25


>Someone was supposed to write up an RFC describing the mapping used for
>class B and C addresses. What is currently being used in the cisco DDN X.25
>implementation is:
>
>	class A: N.H.L.I
>	class B: N.N.H.I
>	class C: N.N.N.HI
>
>Where N represents the network number. H represents the PSN port number. L
>is the logical host field and is still zero.  I is the PSN number. For class
>B addresses, the H field uses the unused L field.

There are people out there using the logical host field on Class A nets.

>For class C addresses,
>the H field lies in the upper four bits of the last octet and the I field
>in the lower four.

We use pretty much the same algorithm in ACC devices except that we tend to
us a 3 bit IMP number and 5 bit Port number split (since IMPs can support
more than 16 hosts).

> I don't know of anyone who has a class C PSN network.

Unless BBN has done it, we probably are the closest.  We actually have a
Class C number that was assigned for use by our test IMP, but we have never
really used it.

						Art Berggreen
						art@acc.arpa

------

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 02:21:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: toothpaste

At one time, some nameless wag asserted that he thought TCP
stood for Tom Cat Piss because it was such a powerful protocol...

Vint

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 May 88 11:34:32 PDT
From:      braden@venera.isi.edu
To:        ietf-hosts@nnsc.nsf.net, kzm@twg.com
Cc:        .@venera.isi.edu, ..., ...., 15:33:53, 19@venera.isi.edu, 88@venera.isi.edu, :@venera.isi.edu, <mogul@decwrl.dec.com>, >, Address@venera.isi.edu, Date:, Did@venera.isi.edu, From:, Here@venera.isi.edu, Internet@venera.isi.edu, It@venera.isi.edu, Jeff@venera.isi.edu, Jeffrey@venera.isi.edu, Mask@venera.isi.edu, Masks@venera.isi.edu, May@venera.isi.edu, Mogul@venera.isi.edu, Mogul's@venera.isi.edu, Nothing@venera.isi.edu, PDT@venera.isi.edu, Standard., Steve@venera.isi.edu, Subject:, Subnetting@venera.isi.edu, Thu@venera.isi.edu, To:, While@venera.isi.edu, a@venera.isi.edu, after@venera.isi.edu, an@venera.isi.edu, and@venera.isi.edu, are@venera.isi.edu, aren't@venera.isi.edu, associate@venera.isi.edu, be@venera.isi.edu, braden@venera.isi.edu, but@venera.isi.edu, can@venera.isi.edu, certainly@venera.isi.edu, clarified@venera.isi.edu, complain@venera.isi.edu, connected@venera.isi.edu, day@venera.isi.edu, different@venera.isi.edu, each@venera.isi.edu, everybody@venera.isi.edu, extracts@venera.isi.edu, for@venera.isi.edu, from@venera.isi.edu, go@venera.isi.edu, host@venera.isi.edu, if@venera.isi.edu, in@venera.isi.edu, intended@venera.isi.edu, is@venera.isi.edu, it@venera.isi.edu, mechanism@venera.isi.edu, meeting@venera.isi.edu, meeting., message@venera.isi.edu, mogul@decwrl.dec.com, network@venera.isi.edu, networks@venera.isi.edu, not@venera.isi.edu, of@venera.isi.edu, our@venera.isi.edu, owner@venera.isi.edu, per-interface@venera.isi.edu, possible@venera.isi.edu, prevents@venera.isi.edu, relevant@venera.isi.edu, running@venera.isi.edu, see@venera.isi.edu, sent@venera.isi.edu, should@venera.isi.edu, single@venera.isi.edu, so@venera.isi.edu, software@venera.isi.edu, some@venera.isi.edu, standard@venera.isi.edu, standard., stored@venera.isi.edu, subnets@venera.isi.edu, subnetting@venera.isi.edu, tcp-ip@venera.isi.edu, tcp-ip@sri-nic.arpa, that@venera.isi.edu, the@venera.isi.edu, theory@venera.isi.edu, they@venera.isi.edu, this@venera.isi.edu, to@venera.isi.edu, two@venera.isi.edu, use@venera.isi.edu, vendor@venera.isi.edu, was@venera.isi.edu, we@venera.isi.edu, what@venera.isi.edu, when@venera.isi.edu, with@venera.isi.edu, wrote@venera.isi.edu, you@venera.isi.edu, your@venera.isi.edu
Subject:   Re: multiple subnet numbers/masks on one wire?

Well, that is not quite the way the some of the other Internet old boys
or the Protocol Czar remember the history.  We believe the question of
multiple masks was always (deliberately) vague.

Jon Postel and I discussed it at length for RFC-1009, and came to the
conclusion that it should be explicitly allowed.  In fact, I came up
with a rationale which you will find in RFC-1009.  That arises from
a simple computation of the addressing issues posed by the Internet
growth.  We now project 10**4 (subnetted) networks and 10**6 hosts in
the (IP) Internet.

To make that fit into subnetted class B networks, taking account of the
bit lossage due to variations of campus sizes, forces one to conclude
that slicing up the bits in various creative ways will be necessary to
survive.  There just are not enough Class B addresses to let places like
Stanford have a bunch; you will HAVE to slice up 16 bits in creative ways!

Now, this argument is based upon the current flat-plus-subnets IP
addressing scheme.  JNC was muttering about a new kind of IP address.
Maybe they will come up with a new approach which will handle the
expansion without multiple subnet masks, but we cannot plan on that yet.

	> In such an implementation, it might be possible to use different masks
	> for different subnets of a single network, but I would not recommend
	> this, since you might find that other implementations cannot handle
	> this; the Standard does not explicitly require that they do so.
	> 
	
Multiple subnet masks has no effect on hosts, only gateways, I claim.
(Steve Deering's point about ICMP Address Mask Reply may be an exception).

	> Moreover, as it has been pointed out, there are subtle problems with
	> this, since in order for a host to choose the right netmask for an
	> outgoing packet, it has to know the self-encoding scheme as well.
	> 
	
I don't think this is right. I think the old mask&match game
still works just fine.

	> If you really need a single "big" subnet and a lot of little ones,
	> consider getting two network numbers.  I find it unlikely, however,
	> that a single subnet with more than a few hundred hosts on it is going
	> to be easily managable.

No, there will not enough Class B networks 5 years from now.
	
	So, if we were to agree with Jeff :
	
	1) all subnet masks within a (standard) network are the same,
	
	2) conformant hosts need support only one subnet mask for an interface 
	which connects to multiple subnets of the same IP network.
	
	But, can two different 'logical' IP networks (NOT subnets) be on the 
	same wire ?  Assuming the answer is yes, we still need a subnet mask per 
	address, and this is another case where we have to examine the class of 
	the IP-address rather than treat it as a flat 32-bit number divided into 
	net/host parts by the address mask.

Sorry, I don't understand why.
	
	Does anyone know if there any other "subtle problems" besides the one
	he cites ?  
	
	For example, I've always wondered what the rules are for assigning subnet 
	numbers and host numbers in a network with multiple subnet masks, since 
	there's a possibility of creating duplicate IP addresses if it's not done 
	correctly :
	
	  on a Class-B network :
	    host-x on subnet-a : mask=FFFFF000, subnet=xxxx1xxx, host=xxxxx101
	    host-y on subnet-b : mask=FFFFFF00, subnet=xxxx11xx, host=xxxxxx01
	
	Keith.
	
Of course, you HAVE to do it correctly!  The simplest approach is to use
the high order bits of the subnet number in a variable-length bit
encoding analogous to Class A, B, C, D, and E addresses.

Bob Braden
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 08:14:31 GMT
From:      FNTA80@BUCLLN11.BITNET ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   RFC822 routes - Thanks.

Several  people (some  *very* knowledgeable)  did care  to answer  to my
posting on this subject. For those  who wonder, the syntax for routes in
RFC822  *does*  use  commas  (I  had overlooked  the  fact  that  a  '#'
specification is used, which implies separation by commas ; ooops..).

Several people also did care to warn me about the fact that many mailers
do *not* support  routes. Don't be worried. I know.  I am the postmaster
here, managing a copy of the  Crosswell mailer, with *no* route support.
But I wanted to  know for sure because I am  distributing an utility for
VM/CMS systems to extract information from RFC822 headers, and I want it
to support the full syntax.

Thanks again.   /AF

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 May 88 16:47:22 PDT
From:      cire@clash.cisco.com
To:        amdcad!phil@ucbvax.berkeley.edu (Phil Ngai)
Cc:        tcp-ip@sri-nic.arpa, cire@clash.cisco.com
Subject:   Re: Need info on Ethernet products for the IBM AT and Sun
>> Date: 19 May 88 18:47:53 GMT
>> From: amdcad!phil@ucbvax.Berkeley.EDU  (Phil Ngai)
>> Organization: Advanced Micro Devices
>> Subject: Re: Need info on Ethernet products for the IBM AT and Sun
>> References: <5503@potomac.ads.com>
>> Sender: tcp-ip-request@sri-nic.arpa
>> To: tcp-ip@sri-nic.arpa
>> 
>> In article <5503@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes:
>> >We would like to network our IBM AT to one of our Sun Microsystems
>> >computers.  The ideal method is to just plug the AT into the Sun's
>>
>> However, with use, cracks and problems show up in PC-NFS. Some are
>> real problems, some might be called a nit but anyway, the product
>> could be improved. 
>> 
>> 3) ftp client blows up on mget with a small number of files, says
>> "Arguments too long".
>> 4) ftp client dies if you go back to telnet too long.

A lot of the problems you have mentioned above but in particular 3 and
4 are a direct result of PC-NFS being built on top of MS-DOG!  The
FTP clint is trying to do an expansion locally but the local command
parser is severally brain-dead so it pukes.  The FTP client dies when
you go to telnet too long because of the single threaded nature of th
box.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 10:33:05 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: FTP server question


Any code which uses TCP which expects TCP to preserve read()/write()
chunking of data (if that's even the abstraction you're using to
communicate with TCP) across the network is BROKEN. TCP doesn't
preserve this information, and anything that expects it to is asking
to lose very loudly.

Even if the application writes a whole block of data in one write(),
there may easily be conditions beyond the control or detection of the
client or server that would cause the TCP to break it up into several
pieces which the other side would see dribbling in as smaller parts
rather than the whole block that was originally written.
-- 
			- john romkey
UUCP: romkey@kaos.uucp			ARPA: romkey@xx.lcs.mit.edu
 ...harvard!spdcc!kaos!romkey		Telephone: (617) 776-3121

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 May 88 17:38:13 PDT
From:      cire@clash.cisco.com
To:        Norman Kincl <norm@atom.hpl.hp.com>
Cc:        hedrick@rutgers.edu (Charles Hedrick), tcp-ip@sri-nic.arpa, cire@clash.cisco.com
Subject:   Re: 802 (.2).3 TCP/IP
>> To: hedrick@rutgers.edu (Charles Hedrick)
>> Cc: tcp-ip@sri-nic.ARPA
>> Subject: Re: 802 (.2).3 TCP/IP 
>> Date: Fri, 20 May 88 10:42:45 PDT
>> From: Norman Kincl <norm@atom.hpl.hp.com>
>> 
>> > while ISO and DECnet phase V will presumably use 802.3.  For token
>> > rings, etc., that have no existing base of TCP/IP implementations, it
>> > appears that only an 802.3 encapsulation will be used.  So we should

Whoops.  That is 802.5 which has an encapsulation that is significantly
different than 802.3.  I am in the process of implementing this stuff
for cisco.  On top of the 802.5 lives 802.2 which is what I think you
are really talking about.  I plan on using 802.2 with the SNAP extension
to allow essentialy an ethernet type field.

>> > not have compatibility problems in practice.  That assumes no vendors
>> > get overly eager in their standard-following and try to do an 802.3
>> > encapsulation for Ethernet.  HP did that, and lost obviously enough
>> > that I think other vendors will be discouraged from following suit.
>> 

cisco also implements 802.2 encapsulations for Ethernet.  We use the
SNAP extensions to properly identify what type the packet is.

>> Are you not confusing 802.3 with 802.2?  802.3 (physical layer) is
>> 
...
>> 802.2 (data link layer) is where the problem comes in.  Though you can have
>> a system that speaks both quite fluently (eg. HP9000 or cisco box), most
>> systems do not do that and provide only one of those data link layers
>> (usually Ethernet).

Much of what was written is really talking 802.2 while saying 802.3

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 12:09:40 GMT
From:      paul@aucs.UUCP (Paul Steele)
To:        comp.protocols.tcp-ip
Subject:   Re: Competition for Bridge

>I have a number for Encore, but will have to track down CISCO.

The number for CISCO is (415) 326-1941 or (800) 553-NETS (which doesn't
work in Canada :-( )

-- 
Paul H. Steele      USENET:   {uunet|watmath|utai|garfield}!dalcs!aucs!Paul
Acadia University   BITNET:   Paul@Acadia
Wolfville, NS       Internet: Paul%Acadia.BITNET@CUNYVM.CUNY.EDU
CANADA  B0P 1X0     (902) 542-2201x587

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 May 88 10:14:31 +0200
From:      "Alain FONTAINE (Postmaster - NAD)" <FNTA80%BUCLLN11.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RFC822 routes - Thanks.
Several  people (some  *very* knowledgeable)  did care  to answer  to my
posting on this subject. For those  who wonder, the syntax for routes in
RFC822  *does*  use  commas  (I  had overlooked  the  fact  that  a  '#'
specification is used, which implies separation by commas ; ooops..).

Several people also did care to warn me about the fact that many mailers
do *not* support  routes. Don't be worried. I know.  I am the postmaster
here, managing a copy of the  Crosswell mailer, with *no* route support.
But I wanted to  know for sure because I am  distributing an utility for
VM/CMS systems to extract information from RFC822 headers, and I want it
to support the full syntax.

Thanks again.   /AF
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 14:05:41 GMT
From:      nsb+@ANDREW.CMU.EDU (Nathaniel Borenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: SendMail

It sounds like you might be interested in the Andrew Message System.  AMS was
designed for the Andrew File System, but also works on NFS or with no central
file system.  Most of it is distributed as part of the Andrew release on the
X11 R2 tape from MIT.  (Some parts of it haven't made it onto the R2 release,
but are expected to be on the R3 release this fall.)  A good overview paper
about it can be found in the February, 1988 USENIX proceedings.  Basically, it
does just about everything you ask for and a whole lot more, including, IF
you're on a high-function workstation running X11, handling multi-media mail
with rasters, animations, music, and so on.

For more information, especially if you can't get ahold of the USENIX paper
and/or MIT release, please send mail to me or to info-andrew@andrew.cmu.edu.

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 15:45:00 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: FTP server question


	
	Unless I misunderstand you there's nothing wrong with the server, it's
	not unusual for a system to produce such a message in two (or more)
	writes and each end up in its own packet, how is the underlying OS
	supposed to know to wait for one more write before shipping the data
	from the first write?
	
Barry,

One might note, just for the record, that both the TCP protocol and most
non-Berkeley implementations of TCP do in fact include a mechanism to
tell the underlying OS when "to wait for one more write before shipping
the data from the first write"... it called PUSH (or PSH). See RFC-793 for
details.  In any case, your basic point that the application level
can have no knowledge of TCP packet boundaries is certainly correct.

Bob Braden

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 17:40:11 GMT
From:      mhw@wittsend..LBP.HARRIS.COM (Michael H. Warfield)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: FTP server question

In article <535@interlan.UUCP> backman@mercury.UUCP (Larry Backman) writes:
>
>	Packet 1 contains a FTP servers Hello message without a CR/LF.
>	Packet 2 contains the CR/LF.
>
>	RFC 959, section 4.2 of the DDN protocol handbook Page 2-773 and 2-774
>	clearly state:
>
>	       "A reply is defined to contain the 3 digit code, followed
>		by Space <SP>, followed by one line of text (where some
>		maximum line length has been specified), and terminated by the
>		Telnet end of line code."
>
>
>	At first glance, the FTP server is at fault.  However, in their
>	defense,  FTP uses TCP, a stream oriented protocol, to ensure 
>	reliable delivery.  This means that the data from a stream can 
>	come out as one single packet, or in the worst case, dribble out
>	as a stream of single bytes.  So in the second case, the split of
>	the FTP message, and the TELNET CR/LF is not so bad.
>

	More to the point is the fact that, to an application, data on a
tcp/ip connection is a structureless stream of bytes.  Any structuring is
imposed by a higher level (i.e.  ftp client / ftp server).  This implies that
tcp/ip packet boundries have no significance to the application (ftp) and may
not even be discernable in many implimentations.  This applies even if there
is a PUSH flag on the tcp/ip packet.  It does not, of course, apply if an
urgent flag is on the data, indicating the last byte of the packet is an
URGENT boundry.  But, then again, ftp does not use that flag for anything.

	RFC 959 concerns the ftp protocol itself and does not relate to
tcp/ip packets or structuring.

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

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 18:15:36 GMT
From:      chuck@excelan.UUCP (Chuck Kollars)
To:        comp.protocols.tcp-ip
Subject:   Re: connecting Internets?

In <44@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes:
> ... The problem I have run into on a continuous basis is the situation 
>where, even though the packets are capable of being seen by all parties, 
>a host rejects a connection because (I think) the destination/source 
>pair are in a different 'subnet' ... Is there any way under legal TCP/IP 
>to get these blasted devices to talk to each other without buying a 
>hardware device such as a gateway or router? ...

If I understand your configuration correctly, you have one Class B
network running on one (very large MAC-bridged) cable, with no need of
subnetworking.  Yet some of your nodes act like they have
subnetworking enabled.  Just disable subnetworking on all your nodes.
Find the "address mask" or "subnetwork mask" or other such
configuration value on each node, and be sure it's set to the value 
that means 'no subnetworking' (probably all zeros).  
[ex:  ifconfig ie0 netmask 0]

Or, maybe you are intentionally using subnetworking and have some
subnetwork routers in your configuration.  But sometimes two different 
subnetworks in fact ride on the same cable.  In which case your 
question is how to have two IP networks on one cable.  For BSD and 
most BSD-derived implementations, the answer is to add a route entry 
for the "other" subnetwork with a metric of 0 hops.  Do this to every 
node.  The metric value 0 hops is interpreted to mean 'on the same 
cable'.  
[ex:  route add 129.253.2.0 129.253.0.99 0]

(Of course, the purist rule is "ONE IP (sub)network <-> ONE cable".  
So convince yourself that you don't have an address administration 
problem before you start hacking.)
-- 
Chuck Kollars,  Excelan, Inc.	mtxinu!excelan!chuck@ucbvax.Berkeley.COM
(chuck@excelan.UUCP)		...!{mtxinu,leadsv,cae780}!excelan!chuck

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      24 May 88 20:26:53 GMT
From:      jch@DEVVAX.TN.CORNELL.EDU (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: Proteon's behaviour

Call Proteon customer service (617/898-3100) and request a boot load
with the test disabled.

Jeff

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 00:38:13 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP

>> To: hedrick@rutgers.edu (Charles Hedrick)
>> Cc: tcp-ip@sri-nic.ARPA
>> Subject: Re: 802 (.2).3 TCP/IP 
>> Date: Fri, 20 May 88 10:42:45 PDT
>> From: Norman Kincl <norm@atom.hpl.hp.com>
>> 
>> > while ISO and DECnet phase V will presumably use 802.3.  For token
>> > rings, etc., that have no existing base of TCP/IP implementations, it
>> > appears that only an 802.3 encapsulation will be used.  So we should

Whoops.  That is 802.5 which has an encapsulation that is significantly
different than 802.3.  I am in the process of implementing this stuff
for cisco.  On top of the 802.5 lives 802.2 which is what I think you
are really talking about.  I plan on using 802.2 with the SNAP extension
to allow essentialy an ethernet type field.

>> > not have compatibility problems in practice.  That assumes no vendors
>> > get overly eager in their standard-following and try to do an 802.3
>> > encapsulation for Ethernet.  HP did that, and lost obviously enough
>> > that I think other vendors will be discouraged from following suit.
>> 

cisco also implements 802.2 encapsulations for Ethernet.  We use the
SNAP extensions to properly identify what type the packet is.

>> Are you not confusing 802.3 with 802.2?  802.3 (physical layer) is
>> 
 ...
>> 802.2 (data link layer) is where the problem comes in.  Though you can have
>> a system that speaks both quite fluently (eg. HP9000 or cisco box), most
>> systems do not do that and provide only one of those data link layers
>> (usually Ethernet).

Much of what was written is really talking 802.2 while saying 802.3

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 05:31:38 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: FTP server question

While it is certainly true that a client that expects any sort of
relationship between TCP segments and logical messages is broken, I
wouldn't let the server get off the hook that easily. Why should it take
two packets to send what should go in one? In this, the first year AJ
(After Jacobson) I would think people would be a little more aware of
such inefficient TCP behavior. :-)

Phil

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 May 88 14:36:36 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   timezones in 822

Hi folks,

    I recall seeing a message on either tcp-ip or header-people a few
months back to the effect that the military timezones specified in
RFC 822 were wrong.  I am now unable to find the message.  A note to
header-people failed to shake it loose. Perhaps some kind soul on TCP-IP
could describe the problem to me again?

Thanks,

Craig
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 15:06:23 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnet numbers/masks on one wire?

Bob - that was an incredible "Cc:" address list on your note - 36 lines.
Some of the more interesting/obscure ones were:

.::., 
33:53@15, 
:@venera.isi.edu, 
 <mogul@decwrl.dec.com>, 
>,
Mogul@venera.isi.edu,
Mogul's@venera.isi.edu,
mogul@decwrl.dec.com,

This fellow 'mogul' probably doesn't have time to do anything
but read mail.  Regards - Craig

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 15:38:46 GMT
From:      hrp@windsor.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   LOOPBACK Net Number

Hmmmm.  Isn't RFC 1009 an obscure place for this information, which is
relevant to many of us who never need to see the inside of a gateway?
This deserves mention in "Assigned Numbers," and perhaps in "Address
Mappings" as well, and certainly in the forthcoming "Requirements for
Internet Hosts" RFC.


Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 15:58:19 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: FTP server question



                                        It does not, of course, apply if an
	urgent flag is on the data, indicating the last byte of the packet is an
	URGENT boundry.  But, then again, ftp does not use that flag for anything.
	
Hmmm. I think you are wrong about the last.  The abort sequence on the top
of page 35 of RFC-959 specifies a Telnet IP - Synch sequence, and the Telnet
protocol spec says that this is to be sent with Urgent.  So, by implication,
a (correctly implemented) FTP does use the TCP Urgent pointer (not a flag!).

Bob Braden
 

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 18:36:36 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   timezones in 822


Hi folks,

    I recall seeing a message on either tcp-ip or header-people a few
months back to the effect that the military timezones specified in
RFC 822 were wrong.  I am now unable to find the message.  A note to
header-people failed to shake it loose. Perhaps some kind soul on TCP-IP
could describe the problem to me again?

Thanks,

Craig

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 18:38:31 GMT
From:      dbd@VX2.GBA.NYU.EDU (Daniel B Dobkin)
To:        comp.protocols.tcp-ip
Subject:   VMS <--> IBM connection

Here's another of those frequently asked questions; trouble is, the
information changes almost as frequently....

We are a large VAX/VMS shop looking for a way to communicate with our
IBM mainframes (MVS).  We've looked quite seriously at the FLEXlink
product; what I need now is to hear from ANYONE with experience with
this product -- anything at all, from war stories to "couldn't live
without it" and whatever's in between.  (For those who don't know,
FLEXlink software provides file transfer, terminal emulation, and
task-to-task capabilites through special hardware that sits between
a VAX and an IBM system.)

I'd also like to hear from anyone who's used (or is familiar with)
ACC's TCP/IP package for MVS.  Are there advantages/disadvantages
to using TCP v. FLEXlink?  (Yes, some are obvious.)

Please reply directly to me -- I'll be glad to summarize whatever I
get back.

thanks,


\dbd
Irving Trust Co.
dbd@gba.nyu.edu
(212) 815 3712

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 19:37:47 GMT
From:      hans@umd5.umd.edu (Hans Breitenlohner)
To:        comp.protocols.tcp-ip
Subject:   Re: Proteon's behaviour

In article <880519-134446-6569@Xerox> Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM writes:
>
>We have noticed some behaviour which seems to be a normal operation on the
>gateway, but that it is very annoying.
>It seems that the Proteon does some self testing of both of its Ethernet
>interfaces and other internal hardware by sending small trash packets to itself
>every so often through both interfaces.
>The frequency of such tests is often enough that it is noticibly consuming
>precious bandwidth already at a premium in our backbone which is carrying a lot
>of XNS traffic.
>

Two packets are sent out every 3.5 to 4 seconds.  While this can be annoying
in many respects, it is hard to see how this could consume much bandwidth.

You can order the software with this feature ("maintenance feature") disabled,
on a per interface basis.  
You should know that, if you do so, you lose the ability of the gateway to
determine if the attached ethernet works.  As a result it may RIP-advertise
reachability of attached subnets when they are actually down.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 19:56:52 GMT
From:      woody@MACOM3.ARPA (robert a woodburn)
To:        comp.protocols.tcp-ip
Subject:   EGP

Can someone provide some general statistics about EGP's operation
at their site.  I'm trying to compile some statistics about average
update sizes and frequency to compare with a protocol being worked on
here.  If anyone already has such figures could you please send me
something representative of the data?

						Thanks Much...
						wood y
						<woody@macom.arpa>

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 20:38:46 GMT
From:      hakanson@mist.cs.orst.edu (Marion Hakanson)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting supported by Sequents?

I hope this is of general interest....

We are running DYNIX 3.0.4 on a Sequent B21, and it does indeed
support subnets (and a settable broadcast address).  According to
the people at Sequent, they put in the 4.3bsd IP networking code,
but are still running the 4.2bsd TCP code (why, I don't know).  This
means that any 4.3bsd systems you have must be configured with the
TCP_COMPAT_42 hack (TCP sequence number bug).  It also includes the
4.3bsd routed and RIP code.

Other than the fact that DYNIX 3.0 does not include a nameserver (or
MX-speaking sendmail), and that it still runs the buggy 4.2bsd ftp,
telnet and rlogin implementations, along with the other 4.2bsd TCP
performance bugs, our Sequent functions adequately as an Internet site
(behind a Cisco router).  The only annoyance I really notice is that
sendmail has the "loop on EOF" bug if an Internet SMTP connection is
lost during a mail transfer (this can be fixed when we port the 4.3bsd
sendmail.MX).

Rick Adams at UUNET may be of help to you, as well.  The UUNET machine
is also a Sequent B21 running DYNIX 3.0.  Don't let my criticisms put
you completely off of the machine.  It is very solid, no crashes, and
has a tremendous amount of CPU bandwidth (by that, I meant it's very
hard to slow the thing down, especially if you have enough RAM).  But
if we didn't have a 4.3bsd machine to handle nameservice and mail
routing, we'd be up a creek.  In short, it ain't 4.3.

-- 
Marion Hakanson         Domain: hakanson@cs.orst.edu
                        CSNET : hakanson%cs.orst.edu@relay.cs.net
                        UUCP  : {hp-pcd,tektronix}!orstcs!hakanson

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 21:59:43 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   LOOPBACK Net Number


Hal Peterson:

See "Internet Numbers" RFC-997 page 5.

--jon.

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 22:20:31 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  LOOPBACK Net Number


	
	Hmmmm.  Isn't RFC 1009 an obscure place for this information, which is
	relevant to many of us who never need to see the inside of a gateway?
	This deserves mention in "Assigned Numbers," and perhaps in "Address
	Mappings" as well, and certainly in the forthcoming "Requirements for
	Internet Hosts" RFC.
	
Well, when it comes to Internet numbers, I only do what I am told
(Jon Postel is my boss).  However, perhaps I misled you.

If you will turn to the latest Internet Numbers RFC, RFC-1020, you will
find the loopback address defined.  Jon mumbled that he plans to move the
special-number rules back to the Assigned Numbers RFC.

So, yes, you are right.

Bob Braden

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 22:32:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple subnet numbers/masks on one wire?


    This fellow 'mogul' probably doesn't have time to do anything
    but read mail.  Regards - Craig

How right you are ... fortunately, the host where I read my mail
was down all morning, so I got some work done.  (Less fortunately,
all those messages addressed to whatever@venera.isi.edu must have ended
up back in Bob's mailbox, since I don't have a mailbox at ISI.)

Ah, the risks of the REPLY command.

-Jeff

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      25 May 88 23:58:18 GMT
From:      john@uw-nsr.UUCP (John Sambrook)
To:        comp.protocols.tcp-ip
Subject:   Re: Honeywell and DG

>In article <8805091745.AA24461@ACC-SB-UNIX.ARPA> chris@ACC-SB-UNIX.ARPA 
 (Chris VandenBerg) writes:
>Good morning all!
>	I am going to be running Honeywell and Data General systems on a
>LAN soon and have been told by a customer that they have TCP/IP implement-
>ations running on them.
>

We are running DG/UX 3.11.1 and have DG/UX TCP/IP installed.  I believe
the product is derived from 4.2BSD (not 4.3) so it may have some of the
bugs that were present in that release.  However, Data General seems to
update it fairly frequently so I imagine reported bugs would be fixed
in a reasonable length of time.

It works fine, modulo the following limitations:

  1.  No support for using nameservers or resolvers.  You have to
      (try to) maintain an up-to-date copy of /etc/hosts.  Not at 
      all easy these days.

  2.  The ping program says one of two things:  "xxx is alive" or
      "no answer from xxx." 

To be fair, I think that some of these will be fixed at the next 
major TCP/IP release (coinciding with DG/UX 4.0).

Hope this helps.

-- 
John Sambrook                        Internet: john@nsr.bioeng.washington.edu
University of Washington RC-05           UUCP: uw-nsr!john
Seattle, Washington  98195               Dial: (206) 548-4386

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 02:32:42 GMT
From:      jt@nrcvax.UUCP (Jerry Toporek)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: FTP server question

In article <535@interlan.UUCP> backman@mercury.UUCP (Larry Backman) writes:
>	[...]
>	At first glance, the FTP server is at fault.  However, in their
>	defense,  FTP uses TCP, a stream oriented protocol, to ensure 
>	reliable delivery.  This means that the data from a stream can 
>	come out as one single packet, or in the worst case, dribble out
>	as a stream of single bytes.  So in the second case, the split of
>	the FTP message, and the TELNET CR/LF is not so bad.
>
>	Needless to say, something bad happens on my end as a result; nothing
>	that I can't hack around, but before doing so, I thought the problem
>	was interesting enough to solicit some other opinions,

You got it all right.  Any piece of stream-based software that makes any
assumption about what it is going to get back from a read is asking for
trouble.

-- 
======================================  `` ''  ===============================
Jerry Toporek                          <`@-@'>          Network Research Corp.
                                        ( > )           1620 Federal Ave. #2
jt@NRC.COM                               \~/            LA, CA, 90025, USA
jt@nrcvax.UUCP                                          (213) 479-6436

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 03:19:45 GMT
From:      tcs@USNA.MIL (Terry Slattery)
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb vs. smart host routing

> Second, the software should have the list of default gateways that I keep
> bringing up rather than just one.

The folks at BRL have done just that in some user mode software that
they cooked up during the times when RIP was still being developed.

They ping the list of gateways with a long time constant to get a
metric on which ones are up and what the error rate is to them.
(Remember, this is only done on the local network where the ping
loading is deemed necessary to support the dynamic reconfiguration.)
If the primary gateway goes down, the user mode process performs a
system call (Unix 4.2/3) to change the default route to one of the
secondary gateways.  The primary gateway is still pinged.  When it
comes back up (or the loss rate becomes acceptable), the pings are
increased in frequency to get a better indication of the link's
operation.  If everything still looks good, the kernel is told to
switch back to the primary gateway.

This type of dynamic routing could be put to good use in systems like
the Excelan VMS product.

	-tcs

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 05:34:13 GMT
From:      garry@batcomputer.tn.cornell.edu (Garry Wiegand)
To:        comp.os.misc,comp.os.vms,comp.graphics,comp.lang.misc,comp.windows.misc,comp.protocols.tcp-ip,soc.singles,news.misc
Subject:   "HELP ME" - Rip-off warning

Chances are greater than zero that "Jay-jay" is a mail fraud: 

   no name was signed to the posting,
   the net address (if it's valid) isn't at the U of Nebraska,
   cash money, no checks, was requested, and
   no street address was given (Jay-jay has an anonymous PO Box).

I may have an unkind mind, but there's a bad smell rising here. 
Followups to news.misc only, PLEASE. Keep your dollars in your pockets.

garry wiegand   (garry@oak.cadif.cornell.edu - ARPA)

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      26 May 1988 10:10-EDT
From:      CLYNN@G.BBN.COM
To:        galbp!wittsend..LBP.HARRIS.COM!mhw@GATECH.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: FTP server question
Re: "last byte of a packet is an URGENT boundary"
The TCP URGENT mechanism uses a pointer; I do not think that there is
any specification which says that packet boundaries are significant
with respect to URGENTs.
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 17:10:00 PST
From:      "Miller, Grant" <miller@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Mailing Lists
TCP-IP@sri-nic.arpa

Please provide mailing list info at earliest convenience.

miller@twg.com

Grant Miller
The Wollongong Group
1129 San Antonio Rd.
Palo Alto, CA 94303

415-962-7207

If I have the wrong mail address please disregard.


-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 14:10:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: FTP server question

Re: "last byte of a packet is an URGENT boundary"
The TCP URGENT mechanism uses a pointer; I do not think that there is
any specification which says that packet boundaries are significant
with respect to URGENTs.

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 15:04:47 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting supported by Sequents?

If you bitch and scream loudly enough, Sequent will send you a
special version of TCP. Its not as good as the latest
Jacobsen/Karels TCP, but it is a tremendous improvement over
what they were shipping. I think it will be included as part
of the next real release.

They do still ship the broken 4.2bsd user programs and don't seem
to care. The good news is that the 4.3bsd source programs
port rather easily. We are running the latest bind and sendmail
on our Sequent and it performs quite well.

It is important to keep yelling at Sequent until they fix it. They
think that their customers don't care about things like 
high performance networking. If enough sites keep complaining, they
might finally fix things.

--rick

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 15:20:50 GMT
From:      execu!dewey@cs.utexas.edu  (dewey henize)
To:        tcp-ip@sri-nic.arpa
Subject:   Getting started
Ok, I'm obviously the slow one here, but...  For some of us, this world of
TCP/IP and networking is a bit tough to pick up.  I didn't have a chance
to learn about it in college so its been strictly OJT.  Would anyone else
out there who has been in this position be willing to send or post a good
solid intro to mid level reading list?

So far I've gotten along alright, but a lot of what I'm doing smacks of black
magic instead of systems administration.  I'm SURE there is a reason for most
of this, and I can't help but believe I can learn it if there is just some
source of this info.

All the same applies to uucp and similiar problems.  L.sys and cousins just
plain confuse me, I don't know how this stuff manages to work together and
I really would prefer to be able to contribute eventually rather than just
skim off the top of others knowledge.
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 15:43:30 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  LOOPBACK Net Number

If it's an "official" number, why doesn't it appear in hosts.txt and
the domain servers?

It would save a lot of people the hassle of configuring it in
their local systems as a special case.

--rick

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 15:44:54 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Proteon's behaviour

In article <2773@umd5.umd.edu> hans@umd5 (Hans Breitenlohner) writes:
>In article <880519-134446-6569@Xerox> Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM writes:
>>
>>It seems that the Proteon does some self testing of both of its Ethernet
>>interfaces and other internal hardware by sending small trash packets to itself
>>every so often through both interfaces.
>
>Two packets are sent out every 3.5 to 4 seconds.  While this can be annoying
>in many respects, it is hard to see how this could consume much bandwidth.
>
>You can order the software with this feature ("maintenance feature") disabled,
>on a per interface basis.  
>You should know that, if you do so, you lose the ability of the gateway to
>determine if the attached ethernet works.  As a result it may RIP-advertise
>reachability of attached subnets when they are actually down.


	If the router does not have a hardware interface test
capability, it's a pain when the interface doesn't work.  Without a
test, it can't even detect a missing xcvr cable.  I think you should
value the interface test.  What Proteon has done is essentially the
ONLY way to do a thorough test of an Ethernet interface that can't
listen to its own transmissions.  All software based tests are only
indicators.  If you disable the test, you have a black hole until you
manually disable the interface.

	Kent England, Boston University

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 18:05:09 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PING with source/record route

Peter,

The original PING (Packet Inter-Net Groper) was written for the fuzzball
circa 1980 and is still in use, although continuously modified, hacked and
abused. I don't think you want that program, which is written in PDP11
assembler and is full of trap doors, Trojan horses and covert channels
(the IP sequence number is really the local millisecond clock, tra la, tra
la). What you probably do want is the Unix PING last heard from BRL. Track
down Mike Minnich (minnich@udel.edu), who has hacked the BRL version to
include record-route and other gizmos.

Dave

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 18:46:25 GMT
From:      wales@valeria.cs.ucla.edu (Rich Wales)
To:        comp.protocols.tcp-ip
Subject:   Re: timezones in 822

In article <8805260153.AA13746@ucbvax.Berkeley.EDU>
craig@NNSC.NSF.NET (Craig Partridge) writes:

    I recall seeing a message on either tcp-ip or header-people a few
    months back to the effect that the military timezones specified in
    RFC 822 were wrong.  I am now unable to find the message.  A note
    to header-people failed to shake it loose. Perhaps some kind soul
    on TCP-IP could describe the problem to me again?

With pleasure.

On page 26 of RFC822 (Section 5.1), the single-letter military time zone
designations are defined with the wrong sign.  For example, "A" is said
to be "-1" (i.e., 1 hour west of UT/GMT), while "N" is said to be "+1"
(i.e., 1 hour east of UT/GMT).

The *correct* definition is as follows:

    East of UT/GMT:  A = +1; B = +2; ...; M = +12
		     (note that "J" is not used)

    West of UT/GMT:  N = -1; O = -2; ...; Y = -12

    UT/GMT itself:   Z = 0

Thus, for example, Pacific Daylight Time in North America can be repre-
sented in RFC822 as "PDT", "-0700", or "T" (*not* "G").

-- Rich Wales // UCLA CS Dept // wales@CS.UCLA.EDU // +1 (213) 825-5683
   3531 Boelter Hall // Los Angeles, California 90024-1596 // USA
   ...!(ucbvax,rutgers)!ucla-cs!wales       ...!uunet!cs.ucla.edu!wales
   "Zounds!  A Gorkon death station appears!  Evasive action!"

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 19:04:15 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  timezones in 822

Craig,

There is only one time zone in the cosmos and that is UT (nee GMT).
There is only one clock in the cosmos and it speaketh UT. All other
timezones are false gods and have meaning only to local holy men. In
Saudi Arabia it is said that midnight occurs at local sundown. In Bombay
and parts of Australia the time zones are on the half-hour and in at least
one spot they are on the quarter hour. And then we get to talk about
summer/winter time.

Those of you who know me have heard this view on a few prior occasions.
Oh yes, the Supreme Clock speaks time in 24-hour format and adds a 61st
second 14 times in the last 16 years. If I set my clock back 1431 days,
what time is it in Sydney? What day? Ponder before answering. If I
write a contract on Blenheim Reef to expire precisely on 1 January 2000
how long, precisely, is it in force? Let's assume a leap-second is
inserted on the previous day. Assume the contract expires based on local
London time. Your answer?

Yeah, I remember a very old message that complained an RFC-822 time zone
was bogus, one of the European zones, I believe. There are at least a
couple of Navy chaps watching these frequencies that should have the answer.

Dave

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 19:29:14 GMT
From:      jonab@CAM.UNISYS.COM (Jonathan P. Biggar)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP server question


	Re: "last byte of a packet is an URGENT boundary"
	The TCP URGENT mechanism uses a pointer; I do not think that there is
	any specification which says that packet boundaries are significant
	with respect to URGENTs.

Not so!  RFC 793 states:

        If there is urgent data the user will have been informed as soon
        as it arrived via a TCP-to-user signal.  The receiving user
        should thus be in "urgent mode".  If the URGENT flag is on,
        additional urgent data remains.  If the URGENT flag is off, this
        call to RECEIVE has returned all the urgent data, and the user
        may now leave "urgent mode".  *****Note that data following the
        urgent pointer (non-urgent data) cannot be delivered to the user
        in the same buffer with preceeding urgent data unless the
        boundary is clearly marked for the user.*****

MIL-STD 1778 has similar language.

Jon Biggar
jonab@cam.unisys.com

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 20:25:00 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   INFO on TCP/IP & Domain Name Server for Honywell DPS-8.

In search of information:
    Does anyone have information on, or a port of, the domain name
    server (bind) for Honywell TCP/IP on a DPS-8 (H 6000) running
    GCOS 8 (release SR3000).

    Also, I would appreciate hearing from anyone currently running this
    software on the Internet.      Thanks in advance,
------------------------------------------------------------------------
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
------------------------------------------------------------------------

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 21:02:15 GMT
From:      rms%columbia-pdn@ACC-SB-UNIX.ARPA (Ron Stoughton acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   reckless TCP packets

Today a driver entered from an on-ramp at 75 MPH, swerved in front of me
across two lanes of traffic, and raced on down the freeway.  His license
number was TCP 810.  I guess it was an urgent packet.

Ron Stoughton, ACC
rms@acc-sb-unix.arpa

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      26 May 88 21:37:58 GMT (Thursday)
From:      Rich <RMRichardson.PA@Xerox.COM>
To:        Craig Partridge <craig@NNSC.NSF.NET>
Cc:        tcp-ip@sri-nic.ARPA, RMRichardson.PA@Xerox.COM
Subject:   Re: timezones in 822
From: Craig Partridge <craig@NNSC.NSF.NET>
>     I recall seeing a message on either tcp-ip or header-people a few 
> months back to the effect that the military timezones specified in RFC 
> 822 were wrong.  I am now unable to find the message.  A note to 
> header-people failed to shake it loose. Perhaps some kind soul on TCP-IP 
> could describe the problem to me again?

From RFC 822:
>           Time zone may be indicated in several ways.  "UT" is Univer-
>      sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
>      mitted as a reference to Universal Time.  The  military  standard
>      uses  a  single  character for each zone.  "Z" is Universal Time.
>      "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
>      lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
>      letter "J" is not used.  The other remaining two forms are  taken
>      from ANSI standard X3.51-1975.  One allows explicit indication of
>      the amount of offset from UT; the other uses  common  3-character
>      strings for indicating time zones in North America.

This appears to be correct if we take "earlier" to mean east and "later" to
mean west of GMT; I remember (from my time in the Navy) that time zone U is
PST (-0800).  

However, just above, RFC 822 says:

>      zone        =  "UT"  / "GMT"                ; Universal Time
>                                                  ; North American : UT
>                  /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
>                  /  "CST" / "CDT"                ;  Central:  - 6/ - 5
>                  /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
>                  /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
>                  /  1ALPHA                       ; Military: Z = UT;
>                                                  ;  A:-1; (J not used)
>                                                  ;  M:-12; N:+1; Y:+12
>                  / ( ("+" / "-") 4DIGIT )        ; Local differential
>                                                  ;  hours+min. (HHMM)

The sign of the on the lettered zones is just reversed of what it should 
be.  

Is this what you were looking for?

Rich

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 00:09:03 GMT
From:      hedrick@ATHOS.RUTGERS.EDU (Chuck Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP

I've just looked at RFC1042 again.  While it is true that I have
in the past tended to confuse 802.3 and 802.3, it's not clear that
I did so in this message.  In a paragraph at the end of the RFC,
it uses language very similar to mine, referring to an 802.3
and an Ethernet link layer as separate standards.  Since 802.3
includes wording saying that there is a length code rather than
a type code, I generally consider that the term 802.3 is properly
applied only to systems whose software actually do that.  This
is of course normally coupled with 802.2 as well.  I did not
mean to imply that 802.3 was used over token ring, etc.  Obviously
there are other 802.x standards for these other media.  What I
was trying to say was that in my view, RFC1042-style encapsulation
will be used for all newer media, but that traditional 10MHz
Ethernet implementations should continue to use the traditional
encapsulation and not the one defined in RFC1042 (which while
it may use the same basic ARP packets, presumes the use of
802.3 and in most cases 802.2, so that the headers put in
front of the ARP packets would make it not interoperable with
a system such as 4.3 BSD).

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 01:10:00 GMT
From:      miller@TWG.COM ("Miller, Grant")
To:        comp.protocols.tcp-ip
Subject:   Mailing Lists

TCP-IP@sri-nic.arpa

Please provide mailing list info at earliest convenience.

miller@twg.com

Grant Miller
The Wollongong Group
1129 San Antonio Rd.
Palo Alto, CA 94303

415-962-7207

If I have the wrong mail address please disregard.

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 08:48:32 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip
Subject:   Re: Proteon's behaviour

In article <22924@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>In article <2773@umd5.umd.edu> hans@umd5 (Hans Breitenlohner) writes:
>>In article <880519-134446-6569@Xerox> Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM writes:
 
>>>It seems that the Proteon does some self testing of both of its Ethernet
>>>interfaces and other internal hardware by sending small trash packets to itself
>>>every so often through both interfaces.
 
>>Two packets are sent out every 3.5 to 4 seconds.  While this can be annoying
>>in many respects, it is hard to see how this could consume much bandwidth.
 
>	If the router does not have a hardware interface test
>capability, it's a pain when the interface doesn't work.  Without a
>test, it can't even detect a missing xcvr cable.  I think you should
>value the interface test.

Software that generates timed transmissions, especially broadcasts, should have
some facility for the interval to be tunable.  In addition to Proteon's
activity, I know Bridge network management has a 45-second "here I am" thing it
does to keep net maps up to date.  Keep-alives are popular topics of net
conversation anyway, but tunable intervals seldom get much air time.  I've
certainly seen my share of networks with rwho disabled for this reason, too.

In most cases, tuning would have to be coordinated netwide, although cases like
the Proteon interface test would be easier to manage.  When you add all these
things together on a large LAN, you'd be amazed at the residual background
activity.

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

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 12:30:03 GMT
From:      tcs@USNA.MIL (Terry Slattery)
To:        comp.protocols.tcp-ip
Subject:   Re:  Need info on Ethernet products for the IBM AT and Sun

We also have the PC-NFS stuff and find that for FTP and TELNET we
prefer to run the NCSA versions.  They will work with the 3Com
card along side the PC-NFS stuff.  The combination solves many
of the problems you mentioned with regard to ftp's mget and server
mode, multiple telnet sessions, etc.  I've also asked the Sun east
coast division folks who are developing the PC-NFS product to
look at the NCSA stuff (they have it) as a design goal for the next
release.
	-tcs
ps.  PC-NFS supports the WD card now and the next NCSA version will
have support for it (reportedly due out this summer).

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 13:49:59 GMT
From:      abe@mace.cc.purdue.edu (Vic Abell)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting supported by Sequents?

In article <8805261504.AA27649@beno.CSS.GOV>, rick@SEISMO.CSS.GOV (Rick Adams) writes:
> If you bitch and scream loudly enough, Sequent will send you a
> special version of TCP.
 .
 . 
 .
> It is important to keep yelling at Sequent until they fix it. They
> think that their customers don't care about things like 
> high performance networking. If enough sites keep complaining, they
> might finally fix things.
> 
> --rick

This is completely different from our experience with Sequent.  They do
care, they do respond -- to polite and informed requests.

Vic Abell

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 14:00:40 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   timezones in 822

In practice, I've never seen anything except time zone Z "ZULU" used
by the military.  Mike

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 15:29:22 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  PING with source/record route

I posted a message about a modified 4.3 PING.  The sources, and minimal
information about, are on lambda.lanl.gov.

	FOR THOSE OF YOU OUT THERE WHO DO NOT RUN THE NAME SERVER:
	
		128.165.4.16

phil wood

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 16:05:22 GMT
From:      merritt@BRL.ARPA (Don Merritt)
To:        comp.protocols.tcp-ip
Subject:   Re:  PING with source/record route

The BRL ping program was modified by Phil Dykstra to handle the record route
option a couple of months ago. It is available for anonymous ftp from host
brl-vgr.arpa as ~ftp/pub/ping.tar. Here is Phil's description of the changes
he made:


	The new ping differs by:
	1) It will only show ICMP error messages when the -v flag is given.
	   This will help reduce confusion from general users.
	2) When IP packet headers are returned in ICMP error messages
	   their headers are dumped broken down by fields.
	3) Identification of ICMP error subcodes is now in the printed
	   messages.
	4) The RECORD_ROUTE option can be included in outgoing packets
	   and the returned route is dumped.
	5) Hostnames for dotted quads are looked up (unless a -n is given).

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 17:16:22 GMT
From:      dlnash@ut-emx.UUCP (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet packet type information requested.

In article <8805231149.AA22588@msr.epm.ornl.gov>, dunigan@MSR.EPM.ORNL.GOV
(Tom Dunigan 576-2522) writes a very informative article which I would
like to add to slightly.

> Current BBN Ethernet and IEEE802.3 "Type" Fields
> 
> 809B	AppleTalk over Ethernet (Kinetics only?)

I believe that this type number has been registered and is "official",
whatever that may mean.  Anyway, Apple uses it as well in their EtherTalk
product.


> Ethernet Vendor Addresses
> 
> 080020	Sun		Sun machines
> 08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
> 			(DEUNA, DEQNA, DELUA)

The Texas Instruments Explorer (a Lisp workstation) has a vendor address
of:

  080028	TI		TI Explorer

Just thought I'd through in my $0.02 worth, if it is worth even that
much....

				Don Nash

UUCP:    ...!{ihnp4, allegra, seismo!ut-sally}!ut-emx!dlnash
ARPA:    dlnash@emx.utexas.edu
BITNET:	 DLNASH@UTADNX, D.NASH@UTCHPC
THENET:  UTADNX::DLNASH, UTCHPC::D.NASH

UUU       UUU
 U         U                The University of Texas at Austin
 U     TTTTUTTTTTTTTT              Computation Center
 U     T   U TT     T
  U       U  TT            "The world is basically non-linear."
   UUUUUUU   TT
             TT 
            TTTT

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 19:17:53 GMT
From:      gcf@actnyc.UUCP (Gordon Fitch)
To:        comp.protocols.tcp-ip
Subject:   Re: Third TCP-IP Book?

I'd like to get the full titles, etc., of the books that were
mentioned.  Unfortunately the original articles have expired
here and I've only been able to read some of the follow-ups.

              -- Gordon Fitch (...!uunet!actnyc!gcf)

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 20:02:47 GMT
From:      kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Getting started
In article <192@execu.EXECU> dewey@execu.EXECU (dewey henize) writes:
>Ok, I'm obviously the slow one here, but...  For some of us, this world of
>TCP/IP and networking is a bit tough to pick up.  I didn't have a chance
>to learn about it in college so its been strictly OJT.  Would anyone else
>out there who has been in this position be willing to send or post a good
>solid intro to mid level reading list?
>
	I just put together a reading list for a brand new employee, a
CS major with little experience with networking and TCP/IP.  See what
you think of this:

	o  a campus network map annotated with IP and DECnet node
numbers [learn by example]

	o  Hedrick, "Introduction to the Internet Protocols" a
tutorial that Charles Hedrick posted some time back and has published
internally at Rutgers as an intro.  Maybe substitute the Davidson or
Comer book(s), if more readily available.

	o  RFC1009, "Requirements for Internet Gateways"

	o  Mockapetris, "Domain Names- Concepts and Facilities" latest
RFC

	o  IDEA0004, Hedrick, "RIP" essential for understanding routed
and any distance vector routing protocol

	o  man pages, Fedor, "Gated"  soon to be published, maybe an
IDEA, ... firewalling and access control 

	o  cisco, "Gateway Reference Manual"  brand new with lots of
intro material

	o  Bosack and Hedrick, "Problems in Large LANs", IEEE
Networks, Jan 88,   all about synchronization and storms, etc

	o  Stallings, "Handbook of Computer- Communications Standards"
all three Vols:
	Vol 1  ISO Reference Model [old]
	Vol 2  IEEE standards [get that IEEE jargon down pat]
	Vol 3  TCP/IP protocol family [not sure how good this is]

	o  RFCs:

	791=	IP
	792=	ICMP
	793=	TCP
	891=	Hello  [I put this in for completeness on routing]
	985, et al=	EGP [maybe you should skip this]
	IDEA9=	new EGP  [there is hope]
	950=	subnetting
	826=	ARP
	1027=	proxy ARP
	903=	RARP
	919/922=broadcasting
	988=	multicast  [premature?]
	894/825=IP on Enet encapsulation


	I guess this is heavily weighted toward routing, since that is
our area of concern.  There is certainly a lot to read.  Track the
IETF IDEAs and ineng-interest for all the latest stuff on routing
exchange protocol improvements coming.

	Perhaps someone else has a list weighted to the applications
(telnet, ftp, smtp, etc) or something better I missed?

	Kent England, Boston University
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      27 May 88 22:38:50 GMT
From:      bdale@hpcsla.HP.COM (Bdale Garbee)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP (was Re: Dumb vs. smart host routing)

/ srg@quick.COM (Spencer Garrett) /  2:15 am  May 18, 1988 /

>Why can't a host just ARP for any destination and expect the
>appropriate gateway(s) to answer?  If there were a hopcount
>field in the ARP record, I think this would solve all the problems.

We (N3CVL, K3MC, and myself) looked very hard about a year ago at 
doing something like this in the KA9Q
Internet Package, to improve the situation on amateur packet radio, where
almost noone can talk directly to anyone else, and so gateway/switch issues
become very important.

I eventually backed away from this idea when it became more clear to me that
a distinction can and perhaps should be maintained between "routing" which
is a logical operation, and "address resolution" which is (to me at least) a
purely physical operation.

However, my recent experience in designing and maintaining a sitewide LAN
at work, including a bunch of discless clusters that for reasons of performance
and cost will be subnetted by putting two ports on each discless server, have
led me to be very interested in Proxy ARP, and other "ARP extensions".  (If only
HP would officially support Proxy ARP in HP-UX... sigh)

My curiosity is up, therefore I also would be interested in comments on 
this subject.

Bdale, N3EUA

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      28 May 88 05:16:38 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  timezones in 822

Mike,

Yup, "Z" is used by aviation, maritime and weather radio and wire as well. 
Actually, I'm bent much less by what you call it than by where the Sun is
when you holler "lunchtime!" To be really picky, the real standard time
told by the fuzzballs is UT-0 (corrected for mean solar rotation in steps
of one second). It is possible to correct this time to 100-ms steps
by listening to the radio broadcasts more carefully (these corrections
are included in the broadcasts as vernier adjustments). If there is a
huge groundswell of anguish that these adjustments are not included
in the existing primary time server chimes, I would be glad to reconsider
the issue. Then you could navigate your yachts by NTP down to the second
or so in longitude. Happy day.

Dave

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      28 May 88 05:37:30 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  timezones in 822

Rich,

Aha! Another greasemonkey! The International Telecommunication Union
(UIT), of which the CCITT and CCIR are parts, recommends the use of "J"
to mean "daylight hours" and "N" to mean "nightime hours" and "X"
to mean both, which should add another zest of grease to this discussion.
We should point out that ISO has already standardized the time
representation, of course. Now, let's talk about Antartica...

Dave

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 May 88 15:11:46 PDT
From:      melohn@Sun.COM (Bill Melohn)
To:        comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25
In article <13652@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>From what I can tell SunLink X.25 does allow carrying IP packets from one lan
>to another via an x.25 virtual circuit.  What I would like to know is how
>transparent this is.  Does one host on the local ip lan (not necessarily the
>Sun running SunLink x.25) just ask to send an ip packet to a node on the
>remote lan, causing SunLink X.25 to open a VC to transmit the packet?

The X.25 virtual circuit is treated exactly the same as a dedicated
serial line connecting two IP hosts together. Routing information
about networks on either side of the link is passed across the link
via the standard Unix RIP. In the resulting internet, any host can
access any other host using whatever IP based services are desired
(note, protocols like NFS require some mount parameter tweaking in
order to not timeout over slower, long haul links).

>Assuming this is the way it works, does SunLink multiplex datagrams from
>several tcp or udp sources over the one VC, and if so, at what point does it
>close the VC?  Are the local and remote lans on different class C ip networks
>(I guess they must be to allow packets to be routed to the host with
>the x.25)?  How are the ip addresses mapped into x.121 addresses?
>Finally from an economic point of view how reasonable is it to send ip
>over x.25 bearing in mind the relatively large tcp + ip headers,
>particularly when you are paying for both connect time and number of
>segments sent (a segment is 64 octets, and NZ telcoms charge for
>unfilled segments as one full one).

As explained above, each VC is treated like a virtual point to point
wire connecting each pair of hosts via the public data network. Each
VC used for IP has a network interface associated with it, with an IP
address of its own. An X.25 circuit manager user process is provided,
which establishes the X.25 virtual circuits to each of the remote
hosts based on a config file, and binds the VCs to the IP network
interfaces used by the kernel routing code. The manager attempts to
keep the VCs connected all the time. This can be expensive if you are
paying for connect time, but since processes like the routing daemon
tend to wake up and send information on a regular basis, the IP
circuits tend to stay active even when they aren't actively being used
for user data transfer.

We are investigating ways to make it practical to create X.25 virtual
circuits only when needed for end-user data transfer, while still
maintaining full routing capabilities and connectivity information.
Our implementation of X.25 Standard services does this on the DDN,
where the X.121 to IP address mapping is fixed, and where routing can
be done by use of a default route to, and redirects from, a core
gateway.
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      28 May 88 22:17:55 GMT
From:      melohn%sluggo@Sun.COM (Bill Melohn)
To:        comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25

In article <13652@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>From what I can tell SunLink X.25 does allow carrying IP packets from one lan
>to another via an x.25 virtual circuit.  What I would like to know is how
>transparent this is.  Does one host on the local ip lan (not necessarily the
>Sun running SunLink x.25) just ask to send an ip packet to a node on the
>remote lan, causing SunLink X.25 to open a VC to transmit the packet?

The X.25 virtual circuit is treated exactly the same as a dedicated
serial line connecting two IP hosts together. Routing information
about networks on either side of the link is passed across the link
via the standard Unix RIP. In the resulting internet, any host can
access any other host using whatever IP based services are desired
(note, protocols like NFS require some mount parameter tweaking in
order to not timeout over slower, long haul links).

>Assuming this is the way it works, does SunLink multiplex datagrams from
>several tcp or udp sources over the one VC, and if so, at what point does it
>close the VC?  Are the local and remote lans on different class C ip networks
>(I guess they must be to allow packets to be routed to the host with
>the x.25)?  How are the ip addresses mapped into x.121 addresses?
>Finally from an economic point of view how reasonable is it to send ip
>over x.25 bearing in mind the relatively large tcp + ip headers,
>particularly when you are paying for both connect time and number of
>segments sent (a segment is 64 octets, and NZ telcoms charge for
>unfilled segments as one full one).

As explained above, each VC is treated like a virtual point to point
wire connecting each pair of hosts via the public data network. Each
VC used for IP has a network interface associated with it, with an IP
address of its own. An X.25 circuit manager user process is provided,
which establishes the X.25 virtual circuits to each of the remote
hosts based on a config file, and binds the VCs to the IP network
interfaces used by the kernel routing code. The manager attempts to
keep the VCs connected all the time. This can be expensive if you are
paying for connect time, but since processes like the routing daemon
tend to wake up and send information on a regular basis, the IP
circuits tend to stay active even when they aren't actively being used
for user data transfer.

We are investigating ways to make it practical to create X.25 virtual
circuits only when needed for end-user data transfer, while still
maintaining full routing capabilities and connectivity information.
Our implementation of X.25 Standard services does this on the DDN,
where the X.121 to IP address mapping is fixed, and where routing can
be done by use of a default route to, and redirects from, a core
gateway.

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      29 May 88 02:53:01 GMT
From:      pf@csc.ti.com (Paul Fuqua)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet packet type information requested.


    Date: Friday, May 27, 1988  12:16pm (CDT)
    From: dlnash at ut-emx.UUCP (Donald L. Nash)
    Subject: Re: Ethernet packet type information requested.
    Newsgroups: comp.protocols.tcp-ip
    
    The Texas Instruments Explorer (a Lisp workstation) has a vendor address
    of:
    
      080028	TI		TI Explorer

After asking around, I believe that the vendor address also applies to
Ethernet boards in TI Business System xxxx's (Sys V Unix boxes);  I
don't know if we make any other Ethernettable hardware.

                              pf

Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet:  pf@csc.ti.com (ARPA too, eventually)
UUCP:   {smu, texsun, im4u, rice}!ti-csl!pf

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      29 May 88 04:03:29 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Re: 3rd TCP-IP book


I spoke with one of the authors, Don Huntington, the other day.
The project has been cancelled and "The Complete Guide to TCP/IP"
will not see the presses after all. So we've got Stallings, Davidson
and Comer for now.

Ole
-------

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      29 May 88 15:12:18 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   How is OOB data supposed to work?


	I'm having a bit of trouble figuring out how out-of-band data works
with stream sockets (i.e. TCP connections) in BSD Unix (I'm using a MtXinu
4.3BSD/NFS vax and a SunOS-3.2 Sun-3).  Hopefully some of you network wizards
out there can set me straight.  My server side looks basicly like:

	sock = socket (AF_INET, SOCK_STREAM, 0);
	bind (sock, &server, sizeof (server));
	listen (sock, 5);
	msgsock = accept (sock, 0, 0);

	while (1)
	{
		rfd = efd = 1<<msgsock;
		select (16, &rfd, 0, &efd, 0);

		if (efd & (1<<msgsock))
			recv (msgsock, buf, 1, MSG_OOB);

		if (rfd & (1<<msgsock))
			read (msgsock, buf, BUFMAX);
	}

	The problem is that once I've recv'd an OOB datum, the select keeps
insisting that there is OOB data pending and the recv keeps re-reading the
same datum.  If some in-line data comes in, depending on the timing, I may see
see the in-line message, or I may not.  For example, when my client is:

	sock = socket (AF_INET, SOCK_STREAM, 0);
	connect (sock, &server, sizeof (server);
	write (sock, "foo", 3);
	send (sock, "X", 1, MSG_OOB);
	write (sock, "bar", 3);

my server does read ("foo"), recv ("X"), read ("bar").  If I insert 2-second
sleeps in front of each write and in front of the send, my server does read
("foo"), recv ("X"), recv ("X"), recv ("X"), ...

	What am I doing wrong?
-- 
Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      29 May 88 23:44:04 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re:  timezones in 822


"Now lets talk about Antarctica..."  

Time there gets interesting, simply because you can cross
so many zones in a small linear distance...  but the interesting
problem is this: When you are at the Pole, every direction
is north, or 000 (recall the color-of-the-bear riddle about
the other Pole).  So how do you fly out?  If you pick any
of the 'norths' at random, all but one of them lead somewhere
other than McMurdo -- and not places you want to go.

The conventional fix to the problem is to superimpose a grid
over the true geography -- graft a piece of the equator
over the pole, so to speak.  Grid north is generally aligned
along the Prime Meridian, so grid south runs along 180,
grid east up the 090 meridian, etc.

Rex Buddenberg

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      30 May 88 00:35:04 GMT
From:      amit@umn-cs.cs.umn.edu (Neta Amit)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc
Subject:   U of MN NetBIOS Gateway to Internet

We are running a PC-LAN of some 20 nodes, with a gateway to the
main departmental Ethernet.  A dedicated AT with 3C501 card serves
as a gateway and mail server (no, we don't use POP), as well as 
file server and print server for the IBM PC Network it's running.

The Gateway software has been developed locally, and our ip/tcp is
derived from MIT's and CMU's pc/ip. Mail was first installed over a
year ago, Telnet is a few months old, FTP is in development. The
machines are fairly loaded, but the load on the gateway is light.

The gateway does as little a processing as possible, e.g. incoming
packets are sent immediately to their destination, where they are
assembled.  As a result, the gateway's capacity is much better than
that reported in similar projects.

Last night we did a little experiemnt which might be of some
interest to this newsgroup. We tried to overload the gateway, by
connecting 14 nodes to it. Two nodes sent mail messages consisting
of the file /etc/hosts (.25MB). The other 12 were logged in
remotely, mostly to local machines, cat'ing /etc/hosts one by one,
in a staggerring fashion.  When we turned the debugging mechanism
on to trace packets at the gateway, we noticed that remote sessions
were running at a reasonable speed, where as Mail was flowing very
slowly.  When the 10th node started to cat, the gateway choked and
died, due to a previously undetected bug. In part, this was due
packet buffer being full.

The buffer's capacity is 20 packets: 4 are permanently assigned to
Mail, 2 in 2 out; another 2 are also dedicated; 14 are for telnet/ftp.
The software is executing in the Small memory model, close to the limit,
hence expansion of the buffer is not very likely.

We then invoked a second gateway. We have the capability to statically
assign different nodes to different gateways on the same subnet, with
no overlapping. The second gateway is a standard AT node, NOT a file
and print server of the PC-LAN. Reconfiguration requires rebooting.
The improvement was instantaneous. Mail began to flow 8 times faster.
Gateway buffers were only half-full. No problem has been noticed.

--Neta Amit (amit@umn-cs.cs.umn.edu)
  University of Minnesota CSci

				   


-- 
  Neta Amit 
  U of Minnesota CSci
  Arpanet: amit@umn-cs.cs.umn.edu

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 May 88 10:54:10 CDT
From:      timk@ncsa.uiuc.edu (Tim Krauskopf)
To:        cire@clash.cisco.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Need info on Ethernet products for the IBM AT and Sun

>To: amdcad!phil@ucbvax.berkeley.edu (Phil Ngai)
>Cc: tcp-ip@sri-nic.arpa, cire@clash.cisco.com
>Subject: Re: Need info on Ethernet products for the IBM AT and Sun 
>Date: Tue, 24 May 88 16:47:22 PDT
>From: cire@clash.cisco.com

>> Date: 19 May 88 18:47:53 GMT
>> From: amdcad!phil@ucbvax.Berkeley.EDU  (Phil Ngai)
>> Organization: Advanced Micro Devices
>> Subject: Re: Need info on Ethernet products for the IBM AT and Sun
>> References: <5503@potomac.ads.com>
>> Sender: tcp-ip-request@sri-nic.arpa
>> To: tcp-ip@sri-nic.arpa
>> 
....
.....
>> 
>> 3) ftp client blows up on mget with a small number of files, says
>> "Arguments too long".
>> 4) ftp client dies if you go back to telnet too long.

>A lot of the problems you have mentioned above but in particular 3 and
>4 are a direct result of PC-NFS being built on top of MS-DOG!  The
>FTP clint is trying to do an expansion locally but the local command
>parser is severally brain-dead so it pukes.  The FTP client dies when
>you go to telnet too long because of the single threaded nature of th
>box.

>Eric B. Decker
>cisco Systems
>Menlo Park, California


Nothing is impossible . . .

Our design for NCSA Telnet supports multiple telnet sessions and FTP in the
background simultaneously under MS-DOS.  Same thing for MacOS and both OS's
are "single-threaded".

You just have to wrap the thread real fast.



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

National Center for Supercomputing Applications (NCSA) 
University of Illinois, Urbana-Champaign
-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      30 May 1988 14:13-EDT
From:      URBANIAK@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA, big-lan@SUVM.ACS.SYR.EDU
Cc:        Urbaniak@G.BBN.COM
Subject:   Ethernet Type Fields and Addresses
Below are the current lists of values known at BBN for: Ethernet
Type Fields; Ethernet Address Vendor assignments; Ethernet
Multicast Address assignments.  As these values are not published
by the IEEE, we maintain these lists for our use, and for distribution.
Please send corrections and updates directly to me at Urbaniak@BBN.COM.

Current Ethernet and IEEE802.3 "Type" Fields		5/5/88

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These are formerly assigned by
Xerox, currently assigned by IEEE. Some assignments are public, others private.
Information currently available includes: Xerox Public Ethernet Packet
Type documentation; IEEE802.3 Std, but not yet further documentation from
IEEE; NIC RFC960; knowledge of some BBN Private Type Field values.

Hex
0000-05EE	IEEE802.3 Length Field
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
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine 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
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
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
809B	EtherTalk (AppleTalk over Ethernet)
80F3	AppleTalk Address Resolution Protocol (AARP)
9000	Loopback (Configuration Test Protocol)
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
Ethernet Vendor Addresses		4/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.

Currently we have noted the following vendor addresses, on the
BBN Corporate Ethernet.

000093	Proteon
0000AA	Xerox		Xerox machines
000102	BBN		BBN internal usage (not registered)
00DD00	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp
08001A	Data General
08001E	Apollo
080020	Sun		Sun machines
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080047	Sequent
08004C	Encore
080068	Ridge
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Physical address for some DEC machines
AA0004	DEC		Logical address for systems running DECNET

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), I am unaware of the algorithm.
Current Ethernet Multicast Addresses		5/5/88

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				designated LanBridge
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-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-FF-FF-FF
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster
				(LAVC Cluster group yy)
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	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      30 May 88 14:45:03 GMT
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Network Management


A couple of weeks ago i sent a message to this list asking
about management tools for TCP/IP type networks. 

One ground rule was the public availability of said tools
(i.e. exclude expensive things, but include things at least
binary avail like tcpdump).

The categories for tools of interest were:

configuration
e.g. 	gated/rip/egp/routed 	- routes
	bind			- names
	rdist			- info distrib.
	info-servers		- distr. info
	db			- ucl distr. account
				  management
	thorn ds		- a nearly real X.500 (but over TCP						  as well as OSI)
				  directory service
	

fault finding/performance 
	ping			- liveness/reachability/errors
	ttcp			- udp/tcp traffic gen.
	etherfind/tcpdump	- protocol behaviour
				- intruder detection...


statistics
	NSStat			- overall net stats
	probe			- ucl icmp based reachability
				  prog.
	flakeway		- ucl PC based fake
				  arpanet
	map			- UCL traffic analyser
				  helps decide where to
				  partition your LAN	

So far i've had 6 replies saying "gosh that would be
a very useful list of info. to collate" and
0 replies saying, "heres a really neat program for
doing everything and it runs on anything bigger than 
a pocket calculator, speaks LAT, X.25, can parse
ASN.1 and pretty print an X.400 header. it also
makes excuses for..."

can anyone help...

jon

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 May 88 15:45:03 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Network Management

A couple of weeks ago i sent a message to this list asking
about management tools for TCP/IP type networks. 

One ground rule was the public availability of said tools
(i.e. exclude expensive things, but include things at least
binary avail like tcpdump).

The categories for tools of interest were:

configuration
e.g. 	gated/rip/egp/routed 	- routes
	bind			- names
	rdist			- info distrib.
	info-servers		- distr. info
	db			- ucl distr. account
				  management
	thorn ds		- a nearly real X.500 (but over TCP						  as well as OSI)
				  directory service
	

fault finding/performance 
	ping			- liveness/reachability/errors
	ttcp			- udp/tcp traffic gen.
	etherfind/tcpdump	- protocol behaviour
				- intruder detection...


statistics
	NSStat			- overall net stats
	probe			- ucl icmp based reachability
				  prog.
	flakeway		- ucl PC based fake
				  arpanet
	map			- UCL traffic analyser
				  helps decide where to
				  partition your LAN	

So far i've had 6 replies saying "gosh that would be
a very useful list of info. to collate" and
0 replies saying, "heres a really neat program for
doing everything and it runs on anything bigger than 
a pocket calculator, speaks LAT, X.25, can parse
ASN.1 and pretty print an X.400 header. it also
makes excuses for..."

can anyone help...

jon

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      30 May 88 18:13:00 GMT
From:      URBANIAK@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Ethernet Type Fields and Addresses

Below are the current lists of values known at BBN for: Ethernet
Type Fields; Ethernet Address Vendor assignments; Ethernet
Multicast Address assignments.  As these values are not published
by the IEEE, we maintain these lists for our use, and for distribution.
Please send corrections and updates directly to me at Urbaniak@BBN.COM.

Current Ethernet and IEEE802.3 "Type" Fields		5/5/88

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These are formerly assigned by
Xerox, currently assigned by IEEE. Some assignments are public, others private.
Information currently available includes: Xerox Public Ethernet Packet
Type documentation; IEEE802.3 Std, but not yet further documentation from
IEEE; NIC RFC960; knowledge of some BBN Private Type Field values.

Hex
0000-05EE	IEEE802.3 Length Field
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
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine 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
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
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
809B	EtherTalk (AppleTalk over Ethernet)
80F3	AppleTalk Address Resolution Protocol (AARP)
9000	Loopback (Configuration Test Protocol)
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
 Ethernet Vendor Addresses		4/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.

Currently we have noted the following vendor addresses, on the
BBN Corporate Ethernet.

000093	Proteon
0000AA	Xerox		Xerox machines
000102	BBN		BBN internal usage (not registered)
00DD00	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp
08001A	Data General
08001E	Apollo
080020	Sun		Sun machines
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080047	Sequent
08004C	Encore
080068	Ridge
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Physical address for some DEC machines
AA0004	DEC		Logical address for systems running DECNET

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), I am unaware of the algorithm.
 Current Ethernet Multicast Addresses		5/5/88

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				designated LanBridge
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-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-FF-FF-FF
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster
				(LAVC Cluster group yy)
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	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      30 May 88 21:32:20 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  timezones in 822

Rex,

Geeze, last I ran phone patches with the KC4 folk at the various US
bases in Antarctica they were keeping Greenwich time but living
US Eastern Time and working radio between 0300 UT and 0900 UT on
whatever frequencies got through. Such hours resulted in some
sleepy wives when I patched them through to their old man stuck
at Palmer Station, which turns out to be, at 64 west longitude,
pretty close to US Eastern Time). Now, I have two QSL cards from
Navy Seebee batallions listing their coordinates as 0W, 90S, which
suggests they salute Greenwich instead. Who cares when you'r humping
theodolites with a SnoCat at 60 below.

By the by, the boys there tell me about the 100-degree club, not so
well known and sort of an initiation haze. The victim takes the
100-degree plus shower, then is thrown out the door in the 100-degree
minus snowdrift. All temperatures are F and the victim is presumably
rescued before his parts start falling off his nude bod.

Dave

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      30 May 88 21:39:42 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting started

Dewey,  Kent England has already responded with a good list of reading 
materials.  I would add that the Comer book,  "Internetworking with TCP/IP",
published by Prentice Hall, ISBN 0-13-470154-2, price $36, is excellent
material for the serious reader.  It gives a lot of "motivational
material" to understand why Internetting is both desirable and not
exactly trivial.  Chuck Hedrick's 25 page intro to TCP/IP and
campus networking is also a handy starter.  There are so many aspects
to networking that is is hard to find the right materials for
each person who is trying to get started.  We try to fill some of the gaps
with tutorials of all flavors (beginner, middle, advanced, and obscure)
and find that people flock to them when they are offered publically.

I hope that Universities will pick up on Comer's book and use it as a
text book.  WE need more people to understand how to design, build
and operate internets.

Dan
-------

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 00:51:58 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting supported by Sequents?

When I politely asked Sequent to provide better TCP support
and SLIP support I was told "the customers dont want it, so
we wont waste time providing it".

When I bitched loudly and publically about it, I got a fixed TCP.

Draw your own conclusions.

--rick

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 04:08:47 GMT
From:      mikep@lakesys.UUCP (Mike Pluta)
To:        comp.protocols.tcp-ip
Subject:   non-*NIX implementations


Is anyone familiar with a NON-*NIX implementation of the TCP/IP protocols?

-- 
Michael J Pluta (mikep@lakesys.UUCP) c/o   | {ihnp4,uwvax}!
Tri-Sys Computer Corp., Inc.               | uwmcsd1!lakesys!
207 East Buffalo Street, Suite 600         | mikep
Milwaukee, WI  53202                       |

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 May 88 10:12:33 EDT
From:      MESSAGE AGENT <ahd@omnigate.clarkson.edu>
To:        TCP-IP@sri-nic.arpa
Subject:   Re: Gateway to Net Ten
	This is an automatic reply.  Feel free to send additional
mail, as only this one notice will be generated.  The following
is a prerecorded message, sent for ahd


27 November 1987

I don't know what to say in this, my last note from Buffalo, New York.
Good and bad things have happened to me since the end of October that
defy description, and the only people who would believe me already have
enough stories to tell about me without creating new legends.  The
people who made the good things happen know who they are, and as for
the bad things... I prefer to lump them together as acts of God and
leave it at that.

However, the end result of those past four weeks is that I now have
survived my first week working for AGS Information Services on site at
IBM Kingston preparing to change software that I'm not allowed to
discuss, I enjoy the work, and I expect it to last a while.  I also
have found an apartment in Kingston, and will be tearing down my
computer to be moved there as soon as I log off.

My new address as of 1 December 1987 is:

	Andrew H. Derbyshire
	578 Broadway, Apt 6
	Kingston, NY 12401

My telephone will be hooked up on 4 December, and the number will be:

	914-339-7425

Note that use of either of these is better than sending me mail on
omnigate, because now that I am working I intend on letting my online
mail exchanges die a natural death and use real world communications
instead.  This advice applies to answering this letter, so please send me
a holiday greeting at 578 Broadway instead of answering this online.

Most of all though, don't be a stranger.

Drew
-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 May 88 16:15:04 EDT
From:      TS1347%OHSTVMA.BITNET@CUNYVM.CUNY.EDU (Tim A Scott)
To:        tcp-ip@sri-nic.arpa
Subject:   BAYNESRT@v880np.NEWPORT
  Mr. Baynes address on the From: line is incorrect.  Please send to:

      baynesrt%v880np.decnet@nusc-npt.arpa


  Tim Scott
  Postmaster at OSU
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 12:43:03 GMT
From:      ken@GATECH.EDU (Ken Seefried iii)
To:        comp.protocols.tcp-ip
Subject:   Re: non-*NIX implimentations


In respose to Micheal J Pluta (mikep@lakesys.uucp),  i know of at least
two non unix tcpip ports.  Here at Ga Tech, we are running TCP/IP on
2 CDC Cyber 180 machines under NOS/VE and on an IBM 4381 under VM.

I do not have the details availible, but if you drop me some e-mail, Ill
be glad to dig them up...

	ken seefried iii	...!{akgua, allegra, amd, harpo, hplabs, 
	ken@gatech.edu		inhp4, masscomp, rlgvax, sb1, uf-cgrl, 
	ccastks@gitvm1.bitnet	unmvax, ut-ngp, ut-sally}!gatech!ken

	soon to be open: ...!gatech!spooge!ken (finally ;'})

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 12:45:00 GMT
From:      Hornig@ALDERAAN.SCRC.SYMBOLICS.COM (Charles Hornig)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Type Fields and Addresses

For those collecting such information, Ethernet type codes 8107, 8108,
and 8109 are assigned to Symbolics, Inc. for internal use.

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 13:20:14 GMT
From:      peter@xios.XIOS.UUCP (Peter Manson)
To:        comp.protocols.tcp-ip
Subject:   Re: PING with source/record route

Thanks very much to everyone who replied to my question about PING.
Here's my interpretation of the various replies:

PING (Packet Inter-Net Groper) was originally written in PDP-11 assembler
for the fuzzball around 1980.  Mike Muuss is the author of the UNIX version.
Phil Dykstra at BRL modified it as follows (Mike Minnich (minnich@udel.edu)
apparently also did some modifications including record route):

	1) It will only show ICMP error messages when the -v flag is given.
	   This will help reduce confusion from general users.
	2) When IP packet headers are returned in ICMP error messages
	   their headers are dumped broken down by fields.
	3) Identification of ICMP error subcodes is now in the printed
	   messages.
	4) The RECORD_ROUTE option can be included in outgoing packets
	   and the returned route is dumped.
	5) Hostnames for dotted quads are looked up (unless a -n is given).

The BRL version can be obtained by public FTP from brl-vgr.arpa (also known
as vgr.brl.mil) in the file ~ftp/pub/ping.tar.

In addition, Phil Wood (the poster of the original message a while ago)
says there are sources on lambda.lanl.gov (128.165.4.16).  I don't know
which version this is.

(I haven't checked these FTP-able sources, since I'm not on the Internet.)

----------------------------------------------------------------------------
Peter Manson			|
XIOS Systems Corp.		|
150-1600 Carling Avenue,	| peter@xios.uucp		from UUCP
Ottawa, Ontario			| xios.uucp!peter@uunet.uu.net	from Internet
K1Z 8R8				|
CANADA				|
(613) 725-5411			|

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 May 88 18:52 EST
From:      BEAME@SSCvax.McMaster.CA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Proxy ARP, routing and Internet Addresses
At McMaster University we have about 600 host (PCs and others) on our
bridged ethernet. We also have a growing number of subnets which usally
consist of one SUN server with two network controllers and several diskless
clients.

We are in the process of connecting to a network which will require "real"
Internet Addresses (we have been using 1.x.y.z).

We feal that a single Class B address cannot handle the growing number of
hosts (over 1024 by year end and around 30 SUN sub-networks).

The solution that I can understand is the aquasition of two Class B
addresses, using one for the main network and subnet the other into 255
sub-networks with 254 hosts each.

I understand what Proxy ARP does, but I don't know if it can (or how it
can) be used to allow us to need only one Internet address.

If I am totaly out in left field, please say so and I will request two
numbers.

-Carl Beame
Beame@McMaster.CA
Beame@McMaster.BitNet

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 14:12:33 GMT
From:      ahd@OMNIGATE.CLARKSON.EDU (MESSAGE AGENT)
To:        comp.protocols.tcp-ip
Subject:   Re: Gateway to Net Ten


	This is an automatic reply.  Feel free to send additional
mail, as only this one notice will be generated.  The following
is a prerecorded message, sent for ahd


27 November 1987

I don't know what to say in this, my last note from Buffalo, New York.
Good and bad things have happened to me since the end of October that
defy description, and the only people who would believe me already have
enough stories to tell about me without creating new legends.  The
people who made the good things happen know who they are, and as for
the bad things... I prefer to lump them together as acts of God and
leave it at that.

However, the end result of those past four weeks is that I now have
survived my first week working for AGS Information Services on site at
IBM Kingston preparing to change software that I'm not allowed to
discuss, I enjoy the work, and I expect it to last a while.  I also
have found an apartment in Kingston, and will be tearing down my
computer to be moved there as soon as I log off.

My new address as of 1 December 1987 is:

	Andrew H. Derbyshire
	578 Broadway, Apt 6
	Kingston, NY 12401

My telephone will be hooked up on 4 December, and the number will be:

	914-339-7425

Note that use of either of these is better than sending me mail on
omnigate, because now that I am working I intend on letting my online
mail exchanges die a natural death and use real world communications
instead.  This advice applies to answering this letter, so please send me
a holiday greeting at 578 Broadway instead of answering this online.

Most of all though, don't be a stranger.

Drew

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 00:31 EST
From:      PMDF Mail Server <Postmaster@GRAD.CIS.TEMPLE.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
Your message could not be delivered to: 

    STAFFORD

Your message has been enqueued and undeliverable for 3 days.
The mail system will continue to try to deliver your message
for an additional 9 days.

The beginning of your message follows: 

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 20:15:04 GMT
From:      TS1347@OHSTVMA.BITNET (Tim A Scott)
To:        comp.protocols.tcp-ip
Subject:   BAYNESRT@v880np.NEWPORT


  Mr. Baynes address on the From: line is incorrect.  Please send to:

      baynesrt%v880np.decnet@nusc-npt.arpa


  Tim Scott
  Postmaster at OSU

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 20:41:37 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25

While we have not used Sun's Sunlink-X25 product, we used the CSNET
X25NET software on a VAX and a GTE Telenet X.25 link for some time. Then
we upgraded our Internet membership from Steerage Class to First Class
by junking X25 and getting a direct HDH connection to an ARPANET PSN. So
I think I can make a few general comments from our experiences in
running IP over X.25.

Yes, it works. But the fact that it does reflects more on the
flexibility and robustness of TCP/IP than on any inherent suitability of
X.25 for serious computer networking (as opposed to remote slow speed
terminal multiplexing, which is what X.25 was designed for and actually
does reasonably well).

An IP-on-X.25 gateway is a complex beast, mainly because of X.25's many
gratuitous complexities.  The most obvious is the need to manage
connections. Interfaces usually support only a limited number of them.
Worse, carriers may decide to charge you for keeping them open even if
they're idle. (Fortunately, Telenet doesn't do this. I guess they're
satisfied with the $1500 you pay them every month just to have a 9600
bps host access line to their network. This is exclusive of usage
sensitive packet charges, more about them later).  The usual strategy
here is to keep your list of open connections sorted in order of time of
last use, so you can close the least recently used connection should you
need to open another one.  Timers can also be used to close idle
connections.

Other problems include inherent performance bottlenecks imposed by the
carrier's own interpretation of the X.25 protocol. For example, Telenet
acts as though the "D-bit" (delivery confirmation bit) in each packet is
set. This means that their packet-layer acknowledgements are on an
end-to-end basis. Unfortunately, the packet size is limited to 128
bytes, and the packet layer window is only 2 packets. This means you
can't send more than 256 bytes on any single virtual circuit per network
round trip time. This can severely limit throughput; in our experience
we could seldom use more than 1/4 of the bandwidth of our 9600 bps
access line with any one virtual circuit.

Since almost all of our IP traffic was to one destination (relay.cs.net)
this would have been a serious performance bottleneck except for a
feature in the gateway code that opened multiple, parallel X.25 virtual
circuits to the same destination and dealt outgoing packets to them in
round-robin fashion. Tannenbaum calls this "downward multiplexing"; I
call it a "kludge". (By the way, this feature comes in very handy when
implementing TCP. There's no other Internet path that gives you such a
chance to test your packet resequencing code!).

But wait, there's more! Not only is an X.25 gateway inordinately
complex, but running it can be very expensive. Telenet, as do all X.25
carriers that I'm aware of, charges for each packet sent.  There is a
nighttime discount, but the figures are still quite high. If you examine
the tariffs, you will find that shipping large files over X.25 can be
*very* expensive. In fact, it is considerably cheaper to use one of the
new 9600 bps dialup modems -- as low as HALF the cost of X.25.  Just to
give you an idea, the last month before we dumped it in favor of our
ARPANET connection, our X.25 path to the Internet through Telenet and
relay.cs.net cost us $10,000. And we did NOT run routing packets over
the path. Even a leased line to Cambridge would have been considerably
cheaper.

Based on my own experiences with IP over X.25, one must wonder what they
were smoking down at the Pentagon when the DoD decided to specify X.25
as the standard interface to the DDN.

Phil

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      31 May 88 23:52:00 GMT
From:      BEAME@SSCvax.McMaster.CA
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP, routing and Internet Addresses

At McMaster University we have about 600 host (PCs and others) on our
bridged ethernet. We also have a growing number of subnets which usally
consist of one SUN server with two network controllers and several diskless
clients.

We are in the process of connecting to a network which will require "real"
Internet Addresses (we have been using 1.x.y.z).

We feal that a single Class B address cannot handle the growing number of
hosts (over 1024 by year end and around 30 SUN sub-networks).

The solution that I can understand is the aquasition of two Class B
addresses, using one for the main network and subnet the other into 255
sub-networks with 254 hosts each.

I understand what Proxy ARP does, but I don't know if it can (or how it
can) be used to allow us to need only one Internet address.

If I am totaly out in left field, please say so and I will request two
numbers.

-Carl Beame
Beame@McMaster.CA
Beame@McMaster.BitNet

END OF DOCUMENT