|
|
ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for July 1988 (348 messages, 243693 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/07.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 Jul 88 02:45:00 GMT From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Wanted: suggestions for an Internet Bibliography
In conjunction with the "Lessons of the Internet" session at SIGCOMM '88, I am compiling a bibliography of published papers, books, etc. that have interesting things to say about the Internet and the Internet Protocols. For example, books such as Douglas Comer's "Internetworking with TCP/IP" and papers such as Lixia Zhang's on TCP Timers, or the upcoming paper by Van Jacobson, are the kind of thing I want. Also, anything that provides real data on how the Internet is used, such as the measured load on networks or gateways, is good. I'm only interested in formally published papers (journals or conference proceedings), technical reports, books, and other similar items. Informal publications, such as RFCs, IENs, and IDEAs, contain a lot of useful information, but they are already well-catalogued, there are an awful lot of them, and they aren't in most libraries. I'm also only looking for papers that say something interesting about the Internet. A paper that simply proposes a protocol is not particularly interesting; a paper that argues for a new or modified protocol based on experience with the Internet is interesting. In essence, I am looking for the literature of the Internet as an experiment, not the standards that define how it is supposed to work. Please mail your answers to me (do not send them to TCP-IP); I will make the results available (probably as an RFC or something like that). Thanks -Jeff
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 04:31:51 GMT From: rcc@k1bc.UUCP (Bob Clements) To: comp.protocols.tcp-ip Subject: TYPE L
Here's a late-filed followup on "TYPE L". A couple of weeks ago there were some messages about "TYPE L". There was some confusion as to what it was really for. The comments said that "L" stood for "Logical". That's wrong. When FTP was first invented there were a fair number of systems on the (then brand-new) ARPANET which were not 8-bit (or 16 or 32) machines. In particular, there were 36 bit DEC machines and 36 bit Honeywell/Multics machines. Each of these machines had its own natural way of storing 8 bit bytes. The storage technique on the DEC-10 machines stored 32 bits in a 36-bit word, leaving four unused bits at the right-hand end of a word. So if you fetched a file from a DEC-10 in 8-bit mode, you could get 32 of each 32 bits that way. But you might want all 36 bits, as in a graphics file or some such. How to distinguish them? The two types "I" and "L" were invented. Type "I" for Image said that you wanted all the bits. The DEC-10 did some shifting and gave you 72 bits (9 octets) from each two words. On the other hand, if all you wanted was a stream of 8-bit bytes, you didn't care about the extra four bits. You used TYPE "L", which stood for LOCAL. It meant that each machine would store the bytes in the most efficient way for its own architecture. Each TYPE was guaranteed reversible. If you stored the bytes in TYPE I and got them back in TYPE I you would get the same file. Similarly for TYPE L. But in between, they might be stored differently, depending on the machine hardware. Un*x FTP's implementor invented the "tenex" command as a shorthand for TYPE L 8, since BBN-TENEX (progenitor of TOPS20) was the most common operating system for DEC-10s on the ARPANET. So there's today's ancient history lesson. Sorry to dredge all that up, but I wrote the first TENEX FTP and I felt an urge to explain. /Rcc clements@bbn.com
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 07:10:20 GMT From: dannyb@kulcs.uucp (Danny Backx) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: TLI transport specific addresses
In article <297@scolex> timon@sco.COM (timon) writes:
>
> a puzzle for the net:
>
>AT+T chose not to define an addressing scheme for their
>TLI library. Instead they require the user program to pass
>to the transport a pointer to an undefined address structure.
>This requires that the user program know what address structure
>the transport is expecting, and therefore makes each user
>program transport specific.
I don't think what you describe is a BAD thing, I think it is a good thing !
Suppose they had defined an addressing scheme in their TLI. In that case you
could only work with that addressing scheme.
What they do now isn't really transport specific. Your programs shouldn't be
using adresses. They should use host names, and transform these host names
into addresses using (e.g.) calls to a name server. These calls provide you
with something, and you can pass a pointer to that something to TLI.
So, in summary : apart from TLI, only the name server should know about
address structures.
-- Danny
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Katholieke Universiteit Leuven
Tel: +32 16 200656 x 3544 | Dept. Computer Science
E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb@blekul60.BITNET | Belgium
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 07:39:04 GMT From: richier@imag.UUCP (Jean-Luc Richier) To: comp.protocols.tcp-ip Subject: Re: gateways and more-than-one-IP-net on one ethernet
In your mail "Re: gateways and more-than-one-IP-net on one ethernet" dated 30 Jun, you say : /* * * Get rid of the Level 2 Bridge(s). Put IP routers in their place. * Don't have two networks on the same LAN. I define LAN as a network * of hosts all sharing the same network address. * * phil wood (cpw@lanl.gov) * */ I agree with. I do not like this construction. However I a not the administrator of this structure, and I have to live with it. I cannot modify the basic concept: 2 LAN linked by a level bridge (When I look to "classical" networks in France, I must be grateful to have at least a TCP/IP LAN, and not the "good" solutions such as DECNET or SNA) Therefore I must survive, and all I can obtain is to put software on some of the machines of the LAN. A good solution would be a a kernel patch to allow adding routes in the kernel according interface and not proxy-arp deaIP addresses, or a proxy arp daemon, to fake route protocols Do you know of such solution. I know that somebody (Barry Shein at Boston University) has written a proxy arp deamon for sun, but I have been unable to contact him. Do you have seen any such software on some site?? Thank Richier richeir@imag.UUCP richier@imag.fr --
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 07/01/88 15:40:16 From: Keith R. Hacke <M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA> To: <tcp-ip@sri-nic.arpa> Subject: Help on TCP/IP for HP
Has anyone networked HP computers (3000s) with IBM PCs and Apple Macintoshs? We have more than 255 devices to ultimately tie together. HP's "TCP/IP" won't do it (they only support class C addresses)! What other TCP implementations will work on the HP? We will be using Kinetics boards with Synoptics ethernet tranceivers built-in on the Macs. All the systems will be on ethernet But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What other TCP implementations exist for HPs? Thanks Keith Hacke MCAIR Telecommunications
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 13:45:53 GMT From: hertzer@rusvx2.rus.uni-stuttgart.dbp.de.UUCP To: comp.protocols.tcp-ip Subject: comer's book in Germany
We paid 76,- DM (Deutsche Mark) for Comer's book with ISBN 0-13-470188-7 Joerg Hertzer Rechenzentrum Universitaet Stuttgart Allmandring 30 D-7000 Stuttgart 80 West Germany Phone: +49 711 685 5803 Telefax: +49 711 682357 Telex: 7255445 (univ d) EARN/Bitnet: ZRFP@DS0RUS1I EAN: HERTZER@RUSVX2.RUS.UNI-STUTTGART.DBP.DE
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 17:36:21 GMT From: hedrick@aramis.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip, richier@imag.imag.fr Subject: Re: gateways and more-than-one-IP-net on one ethernet
route add NETWORK YOURADDRESS 0 where NETWORK is an additional network on the same Ethernet and YOURADDRESS is the address of your machine's interface on that Ethernet. This declares the additional network as being directly connected.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 17:44:08 GMT From: ERINA@ICNUCEVM.BITNET (Erina Ferro) To: comp.protocols.tcp-ip Subject: New OZONE mailing list!
A new computer conference is being formed. Please ignore this message
if you have already received it. Sorry for duplicates.
Please DO NOT ignore this message if it is the first time you read it!
PLEASE FORWARD THIS MESSAGE TO EVERYBODY COULD BE INTERESTED.
This mail is sent you by a group of researchers of the Italian National
Council (C.N.R.), working at the CNUCE Institute, in order to wake up the
sensitivity of people working in the scientific institutions about the
extremely serious problem of the pollution in the world.
As you certainly know, the hole in the ozone, the "hot-house effect",
the acid rains and the toxic waste are disasters provoked by man
by using the Nature as a "never-ending" resource.
Everybody can verify other effects of the pollution, in the cities,
in the seas, in the rivers, etc.
We think that the scientific community must create an opinion movement
able to force some decisions at political level.
We think we are still in time to do something to save Nature
with the help of everybody.
A computing conference is going to be opened and you can partecipate by sending
your ideas to the following address:
OZONE@ICNUCEVM.CNUCE.CNR.IT or
OZONE%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or
OZONE%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT
In order to be included to the list of the partecipants to the conference,
send a mail message to: LISTSERV@ICNUCEVM.CNUCE.CNR.IT or
LISTSERV%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or
LISTSERV%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT
containing only the following line:
SUB OZONE <first name> <surname>
If you need info about the computing conference send a mail message to the
same address containing only the following line:
HELP
Please, inform your collegues about this conference.
Thank you for your collaboration.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 17:47:33 GMT From: rwhite@nusdhub.UUCP (Robert C. White Jr.) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: TLI transport specific addresses
in article <297@scolex>, timon@sco.COM (timon) says:
>
>
> a puzzle for the net:
>
> AT+T chose not to define an addressing scheme for their
> TLI library. Instead they require the user program to pass
> to the transport a pointer to an undefined address structure.
> This requires that the user program know what address structure
> the transport is expecting, and therefore makes each user
> program transport specific.
I think you missed something, as I did. The "address" structure
in question is a standard "netbuf" structure. To write a transport
non-spesific program you must do one extra step, but this is no
big deal; to whit:
When you issue "t_open" on the provider, you will receive a set of
"default" options for the provider, among these are the maximum
size, in characters, of an address and the maximum sizes of
the various data types. These will dictate your address et al.
It is important to remember that the "addresses" refered to by
this are the _names_ assigned to the endpoint in question and
_not_ the physical address/serial_number of the board, to whit:
the address may be associated with different hardware at different
times. As such addresses are arbitrary character strings, usually
numonic, with several "suggested guidleines" for safe naming.
The transport provider bears the burden of translating this
into a media-dependant address, and as such this is not the
problem of your software. The media-address may also be retreived
through one call (I forget which...)
Because the options related to data-packet size et al are prone
to change after connection ("negotiable pramaters") to be
transport independant you should issue t_getinfo and adjust
your sizes accordingly. This is _IMPORTANT_ when you are
using a hetrogenous machine types on the same transport, or when
you are bridging between network types. t_getinfo returns
the "smalest restricted maximums" and therefore prevents
misshaps.
Like dialing a phone, the actual address you use depends on
what you want to reach, and therefore the user has to know
something about what is expected, but the lower-level group
and sub-group or serial-number issues are not really a valid
issue when you are writing the application. If you are
writing a driver, great things can be done for you by aquiring
the network programmers guide (marginally helpful) and an
"unpublished" refrence you can get free with your source code
licence or by request (don't know how much) which I call the
magic book, and they _sometimes_ call the "porting rules"
though this is exactly what they are not, this doccument
is teh one which actually gets around to telling you things
you need to know but are only hinted at in the other
documentation.
"Conssume... enjoy... Tomorrow is for the testing..."
Rob.
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 18:47:47 GMT From: stever@videovax.Tek.COM (Steven E. Rice, P.E.) To: comp.protocols.tcp-ip Subject: Detachable power cords (was "15-pin ethernet connectors")
In article <489@cvaxa.sussex.ac.uk>, Aled Morris
(aledm@cvaxa.sussex.ac.uk) writes:
> . . .
> There are worse connectors...and those are the 3 pin mains leads,
> with absolutely NO RETAINER WHATSOEVER [god, they make me so ANGRY :-)]
> Forget about "ie0: ethernet jammed", one jerk (pun intended) and the
> machine goes down, lock stock and disk heads. Proividing FSCK does not
> make up for saving 50 cents on a decent screw-in cable lock.
Detachable power cords with no locking mechanism are a safety factor.
A few year back, many "twist-lock" connectors were used for power cords,
but fires were caused by cords damaged when someone tripped over a cord
that was securely plugged into the wall on one end and locked into an
instrument on the other end. Many instruments came crashing off tables,
under similar provocation.
Those whose business is safety generally consider aggravation preferable
to injury. . .
Steve Rice
-----------------------------------------------------------------------------
* Every knee shall bow, and every tongue confess that Jesus Christ is Lord! *
new: stever@videovax.tv.Tek.com [phone (503) 627-1320]
old: {decvax | hplabs | uunet | uw-beaver}!tektronix!videovax!stever
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 22:40:16 GMT From: M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke) To: comp.protocols.tcp-ip Subject: Help on TCP/IP for HP
Has anyone networked HP computers (3000s) with IBM PCs and Apple Macintoshs? We have more than 255 devices to ultimately tie together. HP's "TCP/IP" won't do it (they only support class C addresses)! What other TCP implementations will work on the HP? We will be using Kinetics boards with Synoptics ethernet tranceivers built-in on the Macs. All the systems will be on ethernet But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What other TCP implementations exist for HPs? Thanks Keith Hacke MCAIR Telecommunications
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 88 22:43:08 GMT From: MKL@SRI-NIC.ARPA (Mark Lottor) To: comp.protocols.tcp-ip Subject: new domain chart
A new domain chart is now available. The domain system is much bigger than it was last year (the previous chart). To print the new chart you need a postscript printer, paper cutter, tape, and a chair to stand on so you can hang it up. The file pathname is PS:<MKL>DOMAIN.PS You can get it via anonymous FTP from SRI-NIC.ARPA or by sending mail to SERVICE@SRI-NIC.ARPA and putting "SEND filename" in the subject line. It is a little over 100 kbytes. An ascii list is also available as filename "PS:<MKL>DOMAIN.LIST". -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 88 01:22:01 GMT From: guy@gorodish.Sun.COM (Guy Harris) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: TLI transport specific addresses
> It is important to remember that the "addresses" refered to by
> this are the _names_ assigned to the endpoint in question and
> _not_ the physical address/serial_number of the board, to whit:
> the address may be associated with different hardware at different
> times. As such addresses are arbitrary character strings, usually
> numonic, with several "suggested guidleines" for safe naming.
Guess again. Check out the manual page for "t_connect":
In "sndcall", "addr" specifies the protocol address of the destination
transport user, ...
Protocol addresses are generally NOT names and are generally NOT mnemonic; if I
want to know that "seismo.css.gov" is 192.12.141.25, I have to look it up.
"seismo.css.gov" is the name of the machine; its protocol address in the
Internet protocol family is the byte string represented in printed form as
192.12.141.25. (The byte string itself would probably contain 4 bytes with the
decimal values 192, 12, 141, and 25.) The fact that the address is referred to
by a "char *" does not mean it is necessarily a string of printable characters;
it's just a string of bytes ("char" means several things in C, including
"byte").
There may well be protocols in which the protocol address is some form of name
that a human can deal with without too much pain, but neither the Internet
transport/network protocols nor the ISO transport/network protocols have
addresses of that form.
Translating "user-friendly" names to protocol addresses is generally the
responsibility of some layer of software other than the transport-layer or
network-layer protocol implementation. Some protocol families have protocols
for doing this; the Internet protocol family has the domain name server
protocol, which is implemented atop transport-layer protocols (TCP or UDP).
Other mechanisms can be used, such as searching a file (the "host table") or
making queries to other sorts of name servers (e.g., a Yellow Pages server).
Presumably, if one had, say a procedure that took a host name, a service name,
and a protocols family name, and returned the appropriate byte string for the
address of that service on that host in that protocol family, one could write a
transport-independent program to access that service, assuming the service ran
atop several transport layers and didn't depend on particular features of
specific transports.
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 88 03:06:24 GMT From: kgeisel@nfsun.UUCP (kurt geisel) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: SLIP, telnet and ftp on Mac
Phil Karn, KA9Q, has written an implementation of TCP/IP for amateur radio experimenters to communicate over packet radio networks. However, it also happens to be a full implementation of TCP/IP, telnet, ftp, etc. with SLIP and ether support. I use it for everyday stuff because in my opinion it is better than PC/IP and some other ports I have seen. I remember something something about a Mac version floating around. Try calling his Opus BBS: 719-495-2061. +--------------------------------------------------------------------------+ | Kurt Geisel, Intelligent Technology Group, Inc. | | Bix: kgeisel | | ARPA: kgeisel%nfsun@uunet.uu.net US Snail: | | UUCP: uunet!nfsun!kgeisel 65 Lambeth Dr. | | Pittsburgh, PA 15241 | | Know Future | +--------------------------------------------------------------------------+
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 88 22:08:25 GMT From: winter@Apple.COM (Patty Winter) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: SLIP, telnet and ftp on Mac
In article <218@nfsun.UUCP> kgeisel@nfsun.UUCP (kurt geisel) writes:
>Phil Karn, KA9Q, has written an implementation of TCP/IP for amateur radio
>experimenters to communicate over packet radio networks. However, it also
>happens to be a full implementation of TCP/IP, telnet, ftp, etc. with SLIP
>and ether support. I use it for everyday stuff because in my opinion it is
>better than PC/IP and some other ports I have seen. I remember something
>something about a Mac version floating around. Try calling his Opus BBS:
>719-495-2061.
That BBS is actually Bdale Garbee's in Colorado Springs. Phil's code is
also available via anonymous ftp from louie.udel.edu.
Phil originally wrote the code in the DOS environment. A Macintosh port
of it by Mikel Matthews has been around since early this year, and Mikel
is just releasing another version Right About Now. He's getting very busy
with work, however, so some other hams with Macintosh programming
experience are going to be helping with further improvements. Some of them
are on the net, so if you have any Macintosh-specific questions, you might
try asking them here. Phil doesn't have a Macintosh himself, so it's
difficult for him to answer questions about the Macintosh version.
I'm informally keeping a list of everyone who's planning on helping with
the Macintosh code, so if you want to know who else is doing what, feel
free to drop me your name and net address. I'm *not* coordinating anything;
the tradition with Phil's code is that anyone who wants to hack on it is
utterly welcome to do so. I'm simply trying to keep track of who's doing
what so that when someone has a specific question, I can say "write to
so-and-so; he should be able to help." Not being a programmer myself, I
figure this is as good a way as any to make myself useful in promoting
this excellent software. (Yes, I use it myself over amateur radio. I
personally haven't used it on Ethernet or AppleTalk, but I know people
who have.)
Patty
Patty Winter N6BIS [44.4.0.44]
DOMAIN: winter@apple.com UUCP: {decwrl,nsc,sun,dual}!apple!winter
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 88 04:02:33 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip, mckenzie@LABS-N.BBN.COM Subject: Re: ISO VTP
If you'd like to submit an RFC describing ISO VTP, I'd be happy to look at it. As long as descriptions of ISO protocols are not available online, I don't think they're going to make much headway in the Internet community.
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 88 17:14:13 GMT From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) To: comp.protocols.tcp-ip Subject: Re: ISO VTP
It would be nice if the NIC were to furnish the ISO documents on-line. Of course, this would require a significant amount of storage, as they tend to be much more wordy than the equivalent RFCs... :-) -Philip
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 88 21:31:00 GMT From: hollandm@prlhp1.prl.philips.co.uk (Martin Holland) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Name Server for Local Site.
I am looking for a machine to act as a name server for our local site. We have a large, diverse number of machines running TCP/IP. (e.g. IBM, HP, SUN, Apollo, PC, VAX) over our local Ethernet. Trying to keep all the local Hostname Tables in step with each other is becoming a real bind. We thought of using the IBM system as a name server as their implementation of TCP/IP allows for a name server. However it transpires that a prerequisite is SQL to contain the database. We don't have SQL and the cost is horrendous. Does anyone know of any name server software that can either be installed onto one of the existing machines or perhaps a stand-alone system perhaps based on a PC which isn't too expensive. Thanks in advance. M. C. Holland.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 05:02:00 GMT From: YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279) To: comp.protocols.tcp-ip Subject: Excelan/EXOS device driver under Untrix-2.0.
We have a VAX-11/785 running Unix-4.3 (BSD) and using an EXOS card as an
interface to ethernet running the TcpIp protocol (in the dumb mode of EXOS).
We'll replace the BSD o.s. with Ultrix in the future. Has anyone ported the
EXOS device driver from BSD to Ultrix?
Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine, Phones: +972-2-584279, H
Computation Center, +972-2-521574 H
The Hebrew University of Jerusalem, H
Givat-Ram, Jerusalem 91904 H H H
Fax: +972-2-527349 HH H
BITnet: YEHAVI@HUJIVMS H H
InterNet: YEHAVI@VMS.HUJI.AC.IL H
Israeli DECnet: HUJICC::YEHAVI H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Tue, 05 Jul 88 09:24:50 EDT From: Samuel Macias <UDLA%TECMTYVM.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Subscribe
SUBSCRIBE TCP-IP Samuel Macias Thanks
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Tue, 05 Jul 88 09:49:57 EDT From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: Re: ISO VTP
>It would be nice if the NIC were to furnish the ISO documents >on-line. Of course, this would require a significant amount >of storage, as they tend to be much more wordy than the >equivalent RFCs... :-) Also, they tend to be copyrighted (at least my copy of IS 7498 - the basic reference model - is). And rights for copying are assigned to the "local" national standards org (ANSI in the USA).
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 11:53:28 EDT From: Marc Kaplan <KAPLAN@ibm.com> To: tcp-ip@sri-nic.arpa Subject: RFC 1054 and multi-cast protocols
In rfc1054, S. Deering mentions "algorithms and protocols used within and between multicast routers ... will be specified in separate documents" Where/how can I get these "documents"? And where/how can I contact S. Deering. Marc.
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Tue, 05 Jul 88 15:55:33 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: kaplan@ibm.com Cc: deering@pescadero.stanford.edu, tcp-ip@sri-nic.ARPA Subject: re: RFC 1054 and multi-cast protocols
> In rfc1054, S. Deering mentions "algorithms and protocols used within and
> between multicast routers ... will be specified in separate documents"
> Where/how can I get these "documents"? And where/how can I contact
> S. Deering.
Marc:
Unless Steve has something up his sleeve, with the exception of his
paper to be given at the upcoming SIGCOMM, there are, as yet, no
documents specifying how multicast routing is done between routers.
As we speak, there is very active work being done by BBN and
Stanford to test out two differents protocols and sets of algorithms
for routing between multicast agents. The plan is to write up the
results of these experiments in August.
Craig
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jul 88 8:02 +0300 From: Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU> To: info-vax@kl.sri.com, tcp-ip@sri-nic.arpa Subject: Excelan/EXOS device driver under Untrix-2.0.
We have a VAX-11/785 running Unix-4.3 (BSD) and using an EXOS card as an
interface to ethernet running the TcpIp protocol (in the dumb mode of EXOS).
We'll replace the BSD o.s. with Ultrix in the future. Has anyone ported the
EXOS device driver from BSD to Ultrix?
Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine, Phones: +972-2-584279, H
Computation Center, +972-2-521574 H
The Hebrew University of Jerusalem, H
Givat-Ram, Jerusalem 91904 H H H
Fax: +972-2-527349 HH H
BITnet: YEHAVI@HUJIVMS H H
InterNet: YEHAVI@VMS.HUJI.AC.IL H
Israeli DECnet: HUJICC::YEHAVI H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 13:24:50 GMT From: UDLA@TECMTYVM.BITNET (Samuel Macias) To: comp.protocols.tcp-ip Subject: Subscribe
SUBSCRIBE TCP-IP Samuel Macias Thanks
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 13:49:57 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: ISO VTP
>It would be nice if the NIC were to furnish the ISO documents >on-line. Of course, this would require a significant amount >of storage, as they tend to be much more wordy than the >equivalent RFCs... :-) Also, they tend to be copyrighted (at least my copy of IS 7498 - the basic reference model - is). And rights for copying are assigned to the "local" national standards org (ANSI in the USA).
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jul 88 18:26:09 EDT From: karn@thumper.bellcore.com (Phil R. Karn) To: tcp-ip@sri-nic.arpa Subject: large corporate networks
I am writing a paper on our practical experiences in managing Bellcore's internal computer network. It now consists of several dozen Ethernets interconnected by DEC Lan Bridges, Vitalink Translans, point-to-point T1 interlocation links multiplexed on dedicated DS-3 fiber, and a few IP gateways. It now serves roughly 1,000 hosts, almost all of which speak TCP/IP and related protocols. I believe this to be one of the largest networks of its type, and I would like to compare it to other corporate computer networks. Can anyone give me a feel for what other large companies have in the way of internal computer networks? I'd interested primarily in dedicated, high speed (>= 56 kbps) networks with 500 hosts or more. Slow speed "data PBXes" (e.g., Datakit and similar toys) designed primarily for terminal switching don't count. Thanks, Phil Karn
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jul 88 21:54:33 PDT From: suned1!efb@elroy.jpl.nasa.gov (Ev Batey-NSWSES-805/982-5881) To: tcp-ip@SRI-NIC.ARPA Subject: New list for Mot. SYS113x / V68 (ATT SysV) with TCP
I've looked and looked for living members of the Motorola System 113x cult
who run Motorola / AT&T System V Unix / V68 R2/R3.x and have TCP/IP or any
part of it. We have several with CMC ENP-10 and are involved in development.
Unless someone knows of a prior existing list I volunteer to start this one.
To address the list mail to sys-1131. For admin (ADD / DELETE)
sys-1131-request via these paths:
hplabs!motsj1!unicon!suned1!sys-1131
sun!tsunami!suned1!sys-1131
suned1!sys-1131@elroy.JPL.Nasa.Gov
Everett F. Batey II } {UUCP: sun!tsunami!suned1!efb
suned1!efb@elroy.JPL.Nasa.Gov
USNSWSES - Code 4V33 } {ARPA: efbatey@NSWSES.ARPA
Port Hueneme,CA 93043-5007 } {DDD: 805/982-5881 983-1220(ans)
SoCalif SUN Local User Group - Vta-SantaBarbara-SanLuisObispo DECUS
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 16:46:39 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: ISO VTP
In article <8807051529.AA07979@ucbvax.Berkeley.EDU> KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) writes: > [quoting P. Prindeville] >>It would be nice if the NIC were to furnish the ISO documents >>on-line. Of course, this would require a significant amount >>of storage, as they tend to be much more wordy than the >>equivalent RFCs... :-) > >Also, they tend to be copyrighted (at least my copy of IS 7498 - the >basic reference model - is). And rights for copying are assigned to >the "local" national standards org (ANSI in the USA). And they, in turn, assign the rights to sell the printed documents to publishers like Omnicom, who make money selling ISO standards and drafts. Not likely to go on-line anytime soon when Omnicom is making money selling printed copies. Ah, when will we have royalty procedures for on-line publishing??
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 17:37:48 GMT From: mfidelma@bbn.com (Miles Fidelman) To: comp.protocols.tcp-ip Subject: Network Time
FYI: I recently came across a large military network that has an interesting approach to maintaining network time: Each switching center has a Loran-C receiver from which they derive time and clocking. Since the Loran system maintains a very accurate clock (it's intrinsic to proper operation), this all seems to work.
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 17:42:03 GMT From: kumar@hpindda.HP.COM (Krishna Kumar) To: comp.protocols.tcp-ip Subject: Re: Help on TCP/IP for HP
Mr.Hacke, In response to your note: >... HP's "TCP/IP" won't >do it (they only support class C addresses)! Well, this certainly is news to me. I supported TCP/IP, on the 3000 for two years, and there is no limitation on the address type supported. All three classes are supported. You might want to read the manuals to get the facts. >But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What other TCP >implementations exist for HPs? The "junk" TCP/IP transport (Phase II) has been used successfully by HP's proprietary Network Services and recently by The Wollongong Group to develop ARPA services (FTP, TELNET and SMTP). Note that though the services were developed by Wollongong, the Transport is HP's "junk" TCP/IP. This product which has been developed on the aforementioned "junk" TCP/IP is called WIN/H3000 and you should contact Susan Trombetta, The Wollongong Group, 1129 San Antonio Road, Palo Alto, CA 94303-4374. Note that you still need HP's "junk" TCP/IP for the WIN/H3000 product to run. There are no other TCP implementations for the HP3000 other than the "junk" TCP/IP. >Has anyone networked HP computers (3000s) with IBM PCs and Apple Macintoshs? HP is considered a leader in the marketplace for PC to mini integration. You should contact the field/sales office close to you to find what solutions HP has to offer. Warm Regards, Krishna Kumar, Business Networking Division, Hewlett-Packard, Cupertino, CA. ============================================================================= Disclaimer: All opinions expressed are entirely mine and not those of HP. =============================================================================
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 18:08:57 GMT From: wunder@sde.hp.COM (Walter Underwood) To: comp.protocols.tcp-ip Subject: Re: Help on TCP/IP for HP
HP's "TCP/IP" won't do it (they only support class C addresses)! This is not true. I just counted 100 HP3000's on HP's class A network. There are another 30 on MILNET. If the documents don't say how to configure a class A, complain to your field office. Many of the NS/3000 documents assume a single LAN (for historical reasons), but the software knows better. Has anyone networked HP computers (3000s) with IBM PCs and Apple Macintoshs? We have more than 255 devices to ultimately tie together. For IBM PCs, there is a pile of HP software, with names like OfficeShare, PrintCentral, AdvanceMail, and Business System Plus. These use TCP/IP over 802.3 (not Ethernet!), and some non-ARPA services (i.e. proprietary protocols on top of TCP/IP). Wollongong offers FTP, Telnet, and SMTP for the 3000. Again, the link layer only talks 802.3, not Ethernet. Gateways from cisco will talk 802.3 to the 3000, and will forward the packets in Ethernet to systems on the other side of the gateway. HP-UX hosts set up for gatewaying will do the same thing. At this time, that is the only way to talk to an Ethernet-only host. As for Macs, I don't know. I guess that Telnet from the Mac to the Wolly package on the 3000 would be best. The trick is getting an HP terminal emulator on that Mac talking through Telnet. We do have several Macs in our department, but I don't know what we've learned about connecting the two (I don't use either the Mac or the 3000). But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What other TCP implementations exist for HPs? I don't know of any other implementations for current MPE. There was a limited implementation for MPE-III, and that was last seen at White Sands Missle Range. Walter Underwood HP Software Development Environments
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Tuesday, 5 July 1988 22:50:54 EDT From: Eugene.Hastings@morgul.psc.edu To: nsfnet@nnsc.nsf.net, tcp-ip@sri-nic.arpa, nwg@merit.edu Cc: pscnet@morgul.psc.edu, net-maintainers@te.cc.cmu.edu Subject: Network facilities out at PSC, Saturday July 9th
[Apologies to those who see this multiple times, but I figured it's better to see it 3 times than none. Gene] On Saturday, July 9th, the chilled water to part of the PSC facilities will be shut off, interrupting all long distance communications save direct dialup and GTE TELENET. The outage is scheduled to last from 8AM to 4PM, but we hope to have some services restored as early as 2:00PM. Affected systems are: PSN#21, PSC NSS (we may or may not be able to keep the IDNX powered), PSC-GW (10.4.0.14/128.182.1.1), PSC-GW2 (10.1.0.21/128.182.1.7/129.250.15.7), PSCMU-FW (128.182.1.8/128.2.1.1), PSC Fuzzball (128.182.1.2), BELADY (DECNET), MI-Router, Pitt-Router. This means all communications in or out of Mellon Institute, INCLUDING: Transit traffic between ARPANET-NSFNET-PSCNET-SURANET-PRPNET Any DECNET, LAT or TCP/IP between terminals or workstations at Mellon Institute and systems at Westinghouse; ALL exterior TCP/IP traffic to Westinghouse, except from Alcoa; ALL exterior DECNET traffic to Westinghouse, except from Pitt; ALL transit PSCNET traffic (OSU, Case or UMich to ARPA or NSFNET); Transit CCNET (DECNET) traffic to or from the University of Pittsburgh; PRPNET traffic to PSC or the University of Pittsburgh; INTERNET mail to or from PSC; Domain service which relies on CHARON.PSC.EDU (128.182.65.6) Downtime will start at 8AM, and while we hope to have some service back by 1:00 or 2:00, events will impose their own schedule. Since this downtime has been imposed on us, we are going to take full advantage of it, by performing our change to a class C network number on our routing net. 128.182.1.x will be largely replaced by 192.5.146.x. The new assignments are: PSC-GW.PSC.EDU 10.4.0.14, 192.5.146.1, 129.250.15.7 PSC-GW2.PSC.EDU 10.1.0.21, 192.5.146.2 PSCMU-FW.PSC.EDU 192.5.146.3, 128.2.1.1 PSC.NSF.NET 192.5.146.42 MI-RTR.PSC.EDU 192.5.146.6, 128.182.66.1, 128.182.15.1, 128.182.16.1, 128.167.31.2 PITT-RTR 192.5.146.7, 130.49.5.76 NSS 192.5.146.254 We will be changing the name servers like mad to maximize confusion :-) - - - - End forwarded message - - - -
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jul 88 07:37:33 HST From: bill@uhccux.uhcc.hawaii.edu (William J. King) To: TCP-IP@SRI-NIC.ARPA Subject: Re: large corporate networks
WHY ARE WE GETTING TWO COPIES OF TCP/IP NEWTOWK MAIL??
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 22:21:13 GMT From: rochester!ritcv!cxf@cu-arpa.cs.cornell.edu (Charles Fung) To: tcp-ip@sri-nic.arpa Subject: How can I run Proxy ARP on SUN3 gateways
I need to run Proxy ARP on a SUN3/180 to support machines that don't know
about subnets yet. I saw some diffs for BSD4.3 source on the net but
unfortunately my gateway is a SUN. Has anybody out there hacked out some
mods for the SUN OS already? We are currently running 3.5.
Thanks in advance for any help.
---------------------------------------------------------------------------
Charles Fung
Systems analyst
Rochester Institution of Technology
School of Computer Science
Rochester NY
UUCP: seismo!rochester!ritcv!cxf
CSNET: cxf@RIT
MILNET: cxf@CS.RIT.EDU
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 22:56:08 GMT From: ubvax!vsi1!wyse!mips!djl@ames.arc.nasa.gov (Dan Levin) To: tcp-ip@sri-nic.arpa Subject: FTP performance figures
I am trying to get a handle on modern ethernet performance (ok, so so are
a couple of hundred other people...).
FTP binary mode was always one useful measure, and so I am after some numbers.
I would appreciate any results of the following command (or equivalent on your
system):
ftp> binary
200 type set to I
ftp> get /vmunix /dev/null #(you V guys and gals can use /unix)
?????? bytes received in ?.? seconds (????? Kbytes/s)
I am most interested in commercial UNIX boxes running classical user-mode
FTP servers. I need to know the hw/sw configuration of both ends of
the transaction. What I am really after is the fastest implementation out
there. I will post the results if I get enough to notice.
Just to get the ball rolling:
70 Kbytes/Sec. About what an 11/780 running 4.2 would do
100 Kbytes/Sec. Pretty good 680?0 UNIX box
??? Kbytes/Sec. Pretty good modern UNIX box
1000 Kbytes/Sec. Max practical Ethernet throughput
1250 Kbytes/Sec. Max theoretical Ethernet throughput
Thanks,
--
***dan
{decwrl,pyramid,ames}!mips!djl djl@mips.com (No, Really! Trust Me.)
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 88 23:51:19 GMT From: mre@beatnix.UUCP (Mike Eisler) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: TLI transport specific addresses
In article <118@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes: >In article <297@scolex> timon@sco.COM (timon) writes: >>This requires that the user program know what address structure >>the transport is expecting, and therefore makes each user >>program transport specific. > >I don't think what you describe is a BAD thing, I think it is a good thing ! >Suppose they had defined an addressing scheme in their TLI. In that case you >could only work with that addressing scheme. > >What they do now isn't really transport specific. Your programs shouldn't be >using adresses. They should use host names, and transform these host names >into addresses using (e.g.) calls to a name server. These calls provide you >with something, and you can pass a pointer to that something to TLI. Designing a name server to serve two or more network processes using the same transport protocol, but a different transport address scheme is hard. For example RFS from AT&T relies on a name server that will run on top of any TLI-based transport. When the name server is brought up, it reads a file containing host names and TLI addresses in ASCII-hex format. An RFS client must contact the RFS name server to get the address of an RFS server. Well, what if an RFS client and RFS server both support TCP/IP, but different implementations (eg. Lachman and Wollongong) with different address formats? The address of the file server will be incompatible with the client's TCP/IP implementation. Obviously you can work around this by: - by not using a name server and instead supply addresses at mount (connection) time + but you lose the nicety of a central name server - complicating the name server so that each server has multiple addresses. When a client contacts the name server, it could switch on the address of the client to match it to the correct version of the server address. Life would have been simpler had AT&T defined addressing formats for *each* the commonly used protocol suites (DoD/IP, OSI, XNS, DEC NET, SNA, etc.), as well as establishing a registration service. I would have also preferred that the TLI address be expanded from the current opaque one-tuple to an opaque two-tuple. The first field would be the address of "where" the peer is, and the second field would have been the address of "what" the peer is. For example, this would make implementing Sun's NFS over TLI easier, where you have to contact three services (the "whats": PORTMAP, MOUNT, NFS) on the same host (the "place") to establish an NFS "circuit." -mre
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 00:37:27 GMT From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: telnet...
I may be flamed at for suggesting this (and perhaps deservedly so), but I really wish telnet had a "DON'T TELNET-ANYMORE" option. Most telnet server/client interactions happen at connection startup, and then they stay the same until the connection closed. Unfortunately, since telnet options can occur anywhere within the data stream, both telnet processes have to carefully examine every character to see whether it might be an IAC. I wish a host could set the connection up the way that it wanted, and then say "that's it, no more telnet negotiations from me". (Of course, this would make the most sense in binary mode, so that you would not have to worry about end-of-line nonsense either.) Any comments? Bill Westfield cisco Systems. -------
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 00:51:03 GMT From: morgan@jessica.stanford.edu (RL "Bob" Morgan) To: comp.protocols.tcp-ip,comp.edu,comp.dcom.lans Subject: Network simulation for teaching?
I am preparing a class in Computer Networking for a group of students at an industrial site. I'm comfortable with deluging them with lots of reading and lecture, but they're expecting some lab work as well. It was said that they would like to "write a server." I've taught this material to undergrads before, and have observed that writing a simple client (like a UDP echo client) from scratch can be challenging enough. The rub in this case is that the only machine to work with for class purposes is *not* networked, apparently for security reasons. So: does anyone have any sort of network simulation code that would allow students to observe/fiddle with/write network-like code on a single machine? It's running a BSD/Unix variant. (How I can get the code onto the machine is another story . . .). Thanks, - RL "Bob Morgan
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 08:40:00 EST From: "_GOLD::SWEENY" <sweeny%_gold.decnet@gold.bacs.indiana.edu> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: TN3270 for Suns & VMS Vaxen
What kinds of TN3270 products (commercial or 'public') exist for Suns and VMS Vaxen? If you have experience or knowledge of more than one, how do they compare? thanks bunches, Brent Sweeny Indiana University Academic Computing sweeny@gold.bacs.indiana.edu sweeny@iubacs (bitnet)
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jul 88 10:52:57 pdt From: Walter Underwood <wunder@sde.hp.com> To: tcp-ip@sri-nic.arpa, comp.protocols.tcp-ip Subject: Re: large corporate networks
It now serves roughly 1,000 hosts, almost all of which speak TCP/IP and related protocols. I believe this to be one of the largest networks of its type, and I would like to compare it to other corporate computer networks. Sorry, not even close. The HP Internet has about 7500 hosts worldwide (US, Europe, and Japan). We have about 120 gateways, over 200 subnets, and nearly all links are 56Kbit or above. Our link to Japan is 19.2Kbits, but we plan to upgrade it. We are testing a couple of T1 links, and may be installing some cross-country T1 next year, depending on funding. In the US, most of our links are channels on T1s that were bought for our voice network. In Europe, we use 64Kbit X.25 service. We also have two satellite connections. DEC and Xerox have corporate networks with over 10,000 hosts, but they are not TCP/IP (DECNET and XNS, natch). My guess is that the HP Internet is the largest private TCP/IP network, where "private" and "TCP/IP" are necessary qualifiers in order to say "largest". The HP Internet was my first project after coming to HP. It was all modems and UUCP three years ago. Walter Underwood HP Software Development Environments Palo Alto, CA
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 05:01:57 GMT From: oliveb!jerry@ames.arc.nasa.gov (Jerry Aguirre) To: tcp-ip@sri-nic.arpa Subject: 4.3BSD permanent arp entries arn't
We were concerned about one host spoofing another and I thought that presetting the ethernet address in the ARP table would provide some protection. Granted that someone can spoof the actual ethernet address but that requires more effort. What I found was that it didn't work. I used "arp -s" to set the ethernet address and it went into the table. The man page says you have to specify "temp" or it will be permanent. In actuality you have to use the undocumented "perm" keyword to make it permanent. But even when I marked it permanent the ethernet address would change to the value of the system attempting to connect. To test this I set the ethernet address to a value one off from the real system value: arp -s jerry-oatc 2:60:8c:41:97:19 perm I then attempted to rlogin from jerry-oatc to the system where the permanent arp entry was set. It suceeded and a subsequent arp showed that the ethernet address, still flagged as permanent, had changed to the correct value. So, does "perm" mean always keep SOME value around or does it mean keep the specified value around? After we decide maybe we can update the man page to reflect the "perm" keyword and describe what it really does. Jerry Aguirre
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 06:44:14 GMT From: smart@ditmela.oz (Robert Smart) To: comp.protocols.tcp-ip Subject: Re: ISO VTP
Perhaps ANSI in the USA won't allow the ISO standards to be put on-line (are they really that short-sighted?), how about an Internet site in some other country: Canada is the obvious choice. Maybe Australia will be on the Internet some day. What is the situation with making material for which you have local copyright available to a world network? Anyway we don't want the standard ISO documents on-line. They're incomprehensible (except for the CLN documents which are nice). What we want is a description of the protocols that us ordinary folk can read. Bob Smart
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 10:45:12 GMT From: mangler@cit-vax.Caltech.Edu (Don Speck) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: 15 pin ethernet connector
I don't recall any trouble with the slide latches on Xerox 3 Mb/s Ethernet
transceiver cables. The cable was a lot more flexible, though.
Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jul 88 16:30:34 EST From: HEILNER_K@VAXC.STEVENS-TECH.EDU To: tcp-ip@sri-nic.arpa Subject: Unix help...
I am in the process of venturing into the world of Unix. In trying to set up an AT&T 3B, I have noticed that /etc/route and /etc/routed do not exist. Do these files have to exist in order to let the 3B know about the default gateway. We can Telnet to all nodes on the Ethernet but have a problem with connecting to any node on other networks. I have included the default gateway in the /etc/hosts and /etc/networks files without results. Any suggestions?? The 3B is running Unix V5. Also, I know there are lots of Unix books out there, can anyone recommend a good one?? We are having problems receiving mail from the tcp-ip list. Please respond to my address indicated below...thanks Keith Heilner Heilner_k@sitvxb Heilner_k@vaxb.stevens-tech.edu ------------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 13:35:59 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: telnet...
Are you suggesting that one eliminate line mode and only use binary mode? Or are you suggesting that there be an integration of TELNET and the local systems terminal driver? Merton Campbell Crockett
-----------[000046][next][prev][last][first]----------------------------------------------------
Date: 6 Jul 88 13:40:00 GMT
From: sweeny%_gold.DECnet@GOLD.BACS.INDIANA.EDU ("_GOLD::SWEENY")
To: comp.protocols.tcp-ip
Subject: TN3270 for Suns & VMS VaxenWhat kinds of TN3270 products (commercial or 'public') exist for Suns and VMS Vaxen? If you have experience or knowledge of more than one, how do they compare? thanks bunches, Brent Sweeny Indiana University Academic Computing sweeny@gold.bacs.indiana.edu sweeny@iubacs (bitnet)
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 14:32:03 GMT From: ron@topaz.rutgers.edu (Ron Natalie) To: comp.protocols.tcp-ip,comp.edu,comp.dcom.lans Subject: Re: Network simulation for teaching?
One can write network applications local to a single BSD machine. Just use the loopback interface and address (usually 127.0.0.1). -Ron
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 14:38:02 GMT From: Dave_Katz@UM.CC.UMICH.EDU To: comp.protocols.tcp-ip Subject: Re: ISO VTP
>Also, they tend to be copyrighted (at least my copy of IS 7498 - the >basic reference model - is). And rights for copying are assigned to >the "local" national standards org (ANSI in the USA). There is a loophole--draft standards may be distributed free of charge in order to "further the cause of standardization." There is precedent for publishing draft standards as RFCs (8473 [ISO IP], for instance). The trick is getting whoever has the machine-readable source for the text to create straight ASCII for public consumption (and of course the diagrams and such disappear).
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 14:40:15 GMT From: mm06@bunny.UUCP (Michael Murphy) To: comp.protocols.tcp-ip Subject: Are there IP-over-PDN X.25 implementations on SunLink X.25?
Well, are there? The IP-over-X.25 I mean is the one in
use by some csnet members ("x25net"). I am given to understand
that this is a different animal from DDN X.25. Csnet has an implementation
for Unibus and Q-bus vaxes using ACC cards, but we won't be able to
use this. There is a description of the protocol in a 1982 paper by
D. Comer and J. Korb "CSNET Protocol Software: The IP-To-X.25
Interface"; I do not know where this was published.
And now for the Obligatory Request: please mail directly
to me; I will post a summary of the replies.
---
mike murphy mm06@gte.com {harvard,vaxine}!bunny!mm06
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 15:17:00 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Network Time
Miles, Your network is hardly unique. MCI currently synchronizes about a dozen plesiochronous "islands" in their digital telephone network using LORAN-C, Sprint plans to do the same and AT&T plans eventually to use the Global Positioning Satellite (GPS). LORAN-C provides timing to within some tens of nanoseconds (for things like digital telephone synchronization) and in principle can provide UTC verification to wihtin a couple of milliiseconds. It does not provide a UTC timecode, which must be disambiguated by other means. There are no LORAN-C receivers known to me that are designed expressly for time service, as against position service, although some may be capable of rho-rho navigation, which requires a much more precise local clock than the usual hyperbolic navigation. Most folk are expecting GPS to become the system of choice. I do not know if its designers are sensitive to the time-distribution issue. Dave
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 16:47:31 GMT From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) To: comp.protocols.tcp-ip Subject: Re: ISO VTP
I assume you aren't repulsed by the idea of the ISO trying to make money on standards? I believe that they should be able to charge a "handling fee" for printed copies, but if one eliminates (or subsidizes) this cost, what is it to them? -Philip
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 16:54:10 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: telnet...
Bill, There are Telnet controls (eg IP, AO, AYT...) that can appear at any time in the stream, and a correct implementation must check for them. An implementation that does not is not implementing the Telnet protocol (RFC-764). Bob Braden
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 17:53:43 GMT From: mar@ATHENA.MIT.EDU To: comp.protocols.tcp-ip Subject: telnet...
A "DON'T TELNET ANYMORE" option can save you a whole lot on efficiency. I don't just mean taking a couple of conditionals out of the main loop in a telnet server. For example, on the ITS operating system, the supdup server was only involved in starting up a connection. Once the connection was established, a system call tied the network connection to the pseudo-tty that the command interpreter was on, and the server process was no longer in the loop. If there was a way to make sure that no more telnet options processing would need to be done, a similar thing could be done with telnet on other operating systems, saving 2 process-switches per character. -Mark
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 19:01:30 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Network simulation for teaching?
Bob, You are in luck. A BSD implementation of TCP/IP should work just dandy hooked up to no network at all in the physical sense. All the code is written so that the source and destination processes can be on any machine including the same machine. You may have to fiddle with a config file to get it to "loop back" properly, but it should all work. Dan -------
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 88 19:23:52 GMT From: zgel05@apctrc.UUCP (George E. Lehmann) To: comp.protocols.tcp-ip Subject: flooded with routing updates?
Tulsa, Oklahoma Keywords: Has anyone else had problems with excessive routes showing up at their site? On three occassions in the past thirty hours we have suddenly discovered 500-700 internet addresses in our Sun's route tables. Things generally go poorly until we kill off the router daemons, flush the tables and restart /etc/in.routed. Any comments or similar occurrences? -- George Lehmann, ...!uunet!apctrc!zgel05 Amoco Production Co., PO BOX 3385, Tulsa, Ok 74102 ph:918-660-4066 Standard Disclaimer: Contents are my responsibility, not AMOCO's.
-----------[000056][next][prev][last][first]----------------------------------------------------
Date: 7 Jul 88 00:04:41 GMT
From: torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To: comp.protocols.tcp-ip
Subject: Re: ISO VTP>There is a loophole--draft standards may be distributed free of charge >in order to "further the cause of standardization." There is precedent >for publishing draft standards as RFCs (8473 [ISO IP], for instance). >The trick is getting whoever has the machine-readable source for the >text to create straight ASCII for public consumption (and of course >the diagrams and such disappear). > Could something be done to generate a Postscript copy of it? Most people can at least get access to such a device somewhere close by.... And it should not be difficult to argue that distributing these documents across the Internet *would* indeed further the cause of standardization. Who could ``do something" to make this happen? ANSI? NBS?
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Thu, 07 Jul 88 08:33:41 -0400 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: "George E. Lehmann" <apctrc!zgel05@UUNET.UU.NET> Cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: flooded with routing updates?
... we have suddenly discovered 500-700 internet addresses
George,
Any hint of whether they are registered nets (have names in the file
NIC:<netinfo>hosts.txt)? Which routing protocols are you running?
... restart /etc/in.routed.
Who do you run RIP with? "Who do you trust?"
Mike Brescia
BBNCC Gateway Dev.
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Thu, 07 Jul 88 13:01:58 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@sri-nic.ARPA Subject: Network Management Documents
As many of you know, two working groups of the Internet Engineering Task
Force have been working madly to finalize documents describing proposed
standards for network management in TCP-IP networks. These efforts are
a result of the recommendations in RFC 1052.
This note is to let you know that one of these two working groups,
the Management Information Base (MIB) Working Group, is about to report
two documents to the RFC editor. The first document describes the
structure of management information, how management data is structured
and represented in the MIB. The second document describes the required
management instrumentation of a TCP-IP system. It is expected that
these documents will eventually become Internet standards.
We are currently in the last stages of the comment period on the
documents. Comments can be sent to me (as WG chair) until *Wednesday
July 13th.* For those people interested in reviewing the documents, they
are available on-line by anonymous FTP:
Structure of Management Information:
at SRI-NIC.arpa: <ietf>idea0023-00.txt
Management Information Base
at NNSC.NSF.NET: pub/idea0024-01.txt
*PLEASE NOTE* that at this stage in the comment period we are only accepting
comments which help us clarify definitions. Unless you believe we have made
a truly gross technical error please do not suggest that we add additional
instrumentation or restructure the MIB.
Craig Partridge
Chair IETF MIB Working Group
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 06:43:36 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: telnet...
The performance problem you refer to (2 process switches/character) is an artifact of the design of the Telnet server and operating system and not a problem in the Telnet protocol itself. In WAITS, Tenex, and TOPS-20, the Telnet server is in the same context as the terminal driver (that is, it is part of the operating system). A Telnet terminal is a special type of software terminal. It is not a pseudo-terminal because there is no controlling job. It's more like a physical terminal, but instead of the characters coming from a hardware RS232 line scanner they're coming from the TCP/IP driver. I believe a similar design is used by Unix; I don't believe Unix has a Telnet server running at process level. -------
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Thu, 07 Jul 88 11:08:37 EDT From: Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU> To: William Westfield <BILLW@MATHOM.CISCO.COM>, tcp-ip@SRI-NIC.ARPA Subject: Re: telnet...
Since Bill Westfield asked for flames: :-) >I really wish telnet had a "DON'T TELNET-ANYMORE" option. Most telnet >server/client interactions happen at connection startup, and then they >stay the same until the connection closed. Unfortunately, since telnet >options can occur anywhere within the data stream, both telnet processes >have to carefully examine every character to see whether it might be an >IAC. I wish a host could set the connection up the way that it wanted, >and then say "that's it, no more telnet negotiations from me". (Of course, >this would make the most sense in binary mode, so that you would not have >to worry about end-of-line nonsense either.) > >Any comments? Why use Telnet if you don't want it? It certainly isn't that difficult to keep scanning for IAC, and Telnet is certainly not a very complex protocol. And you always have the option of rejecting any changes in options if you don't want to deal with them. In what circumstances would you want to use this feature? In a general interactive environment, it would seem like you'd want to keep your options open. What concerns me, though, is that some Telnet implementations apparently assume that no more options will be negotiated after the startup, and then stop working when they encounter software that sends them, such as echo toggles for password suppression. Doug Nelson Michigan State University Computer Lab
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 88 14:10 PDT From: Dale Smith <DSMITH@oregon.uoregon.edu> To: tcp-ip@sri-nic.arpa, big-lan@SUVM.BITNET Subject: NI5210 in a Toshiba T3200?
I am getting ready to go out and buy a portable machine, a fast ethernet board, and FTP software's LANwatch to use as a network monitor for our campus network. The major question is, does anyone have any experience running the NI5210 in machines with a fast bus (12Mhz), and specifically, is there anyone out there running an NI5210 in the Toshiba T3200? Any comments on this proposed configuration are welcome. 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
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 09:59:06 GMT From: swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: Re: TN3270 for Suns & VMS Vaxen
tn3270 is a product of Greg Minshall, not a class of programs (it carries a Berkeley copyright). It works fine on Suns. The only question is how you want your keys mapped. We have a "tn3270.sun3.bin.tar[.Z]" FTPable from devvax.tn.cornell.edu -- I'm not sure how up to date the executable is but the keymapping is quite nice (I believe Melanie Nesheim put it together before going to work for Thinking Machines). To be sure of getting an up-to-date executable you should go to Berkeley. For VMS, all I know of is that TWG distributes tn3270 to run under Eunice. There has to be something better somewhere, but all I find is rumors. I'd really like to hear about a native 3270 emulator for VMS too. Scott
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Thu, 07 Jul 88 18:20:22 -0400 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: mar@ATHENA.MIT.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: telnet...
A "DON'T TELNET ANYMORE" option can save you a whole lot on efficiency.
Yes, making a direct path from the net driver to the terminal driver is much
more efficient. You do need the escape route however. 10 years ago (or was
that when it was done in ITS) there was talk of having the telnet server throw
such a switch, which meant "pass everything transparently between terminal and
net until you see a special character". That would be IAC in the direction of
net->term and one of BREAKSET in the term->net direction. Once the escape
character was encountered the server would have to interpret again, until it
was satisfied to put the path in transparent mode again.
If there was a way to make sure that no more telnet options processing
would need to be done, a similar thing could be done with telnet on
other operating systems, saving 2 process-switches per character.
Since there is always option processing going on, you just invoke the server
for the characters it needs to handle. IAC-IAC doubling would be expensive,
but how often do you transfer the character 0xFF?
Regards,
Mike
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 12:33:41 GMT From: brescia@PARK-STREET.BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: Re: flooded with routing updates?
... we have suddenly discovered 500-700 internet addresses
George,
Any hint of whether they are registered nets (have names in the file
NIC:<netinfo>hosts.txt)? Which routing protocols are you running?
... restart /etc/in.routed.
Who do you run RIP with? "Who do you trust?"
Mike Brescia
BBNCC Gateway Dev.
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 88 21:11:33 PDT From: melohn@Sun.COM (Bill Melohn) To: comp.protocols.tcp-ip Subject: Re: large corporate networks
In article <8807061752.AA04284@sde.hp.com> wunder@SDE.HP.COM (Walter Underwood) writes: >Sorry, not even close. The HP Internet has about 7500 hosts >worldwide (US, Europe, and Japan). We have about 120 gateways, over >200 subnets, and nearly all links are 56Kbit or above. Our link to >Japan is 19.2Kbits, but we plan to upgrade it. We are testing a >couple of T1 links, and may be installing some cross-country T1 next >year, depending on funding. > >DEC and Xerox have corporate networks with over 10,000 hosts, but >they are not TCP/IP (DECNET and XNS, natch). My guess is that the HP >Internet is the largest private TCP/IP network, where "private" and >"TCP/IP" are necessary qualifiers in order to say "largest". Sun's Wide Area Network (SWAN), has HP beat; as of 2 minutes ago we had more than 7700 registered IP hosts on more than 500 registered networks and subnets worldwide. We are also most likely the fastest growing private net as well, with a growth rate of some 200 nodes a month! We have links from 9600 baud up to T1 speeds, using Sun Ethernet gateways, Sunlink Internetwork Routers, and Sunlink X.25 software to tie nodes from Japan and the far east to the US, Canada, and Europe.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 14:49:35 GMT From: hrp@rothko.CRAY.COM (Hal Peterson) To: comp.protocols.tcp-ip Subject: telnet...
Mark, But who is going to take care of NVT if not a telnet server? A very lightweight telnet server perhaps. . . . Hal
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 15:08:37 GMT From: 08071TCP@MSU.BITNET (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: telnet...
Since Bill Westfield asked for flames: :-) >I really wish telnet had a "DON'T TELNET-ANYMORE" option. Most telnet >server/client interactions happen at connection startup, and then they >stay the same until the connection closed. Unfortunately, since telnet >options can occur anywhere within the data stream, both telnet processes >have to carefully examine every character to see whether it might be an >IAC. I wish a host could set the connection up the way that it wanted, >and then say "that's it, no more telnet negotiations from me". (Of course, >this would make the most sense in binary mode, so that you would not have >to worry about end-of-line nonsense either.) > >Any comments? Why use Telnet if you don't want it? It certainly isn't that difficult to keep scanning for IAC, and Telnet is certainly not a very complex protocol. And you always have the option of rejecting any changes in options if you don't want to deal with them. In what circumstances would you want to use this feature? In a general interactive environment, it would seem like you'd want to keep your options open. What concerns me, though, is that some Telnet implementations apparently assume that no more options will be negotiated after the startup, and then stop working when they encounter software that sends them, such as echo toggles for password suppression. Doug Nelson Michigan State University Computer Lab
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 15:30:53 GMT From: ted@gouldnl.UUCP (Ted Lindgreen) To: comp.protocols.tcp-ip Subject: Re: NAMED and IP forwarding
>What version of UTX is it that supports NAMED and IP forwarding? UTX 2.0 and later supports IP forwarding (provided that you have configured it in the CONFIGURATION file. NAMED is supported on UTX/32S 1.1, UTX/32 2.1 and UTX/32 3.0 -- | Ted Lindgreen ...!mcvax!gouldnl!ted | | Gould European Unix Support Centre ted@gouldnl.nl | | Maarssenbroek, The Netherlands (USA) ...!gould!tlindgreen |
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 15:37:10 GMT From: Dave_Katz@UM.CC.UMICH.EDU To: comp.protocols.tcp-ip Subject: Re: ISO VTP
>Could something be done to generate a Postscript copy of it? Most people >can at least get access to such a device somewhere close by.... And it should >not be difficult to argue that distributing these documents across the >Internet *would* indeed further the cause of standardization. Who could ``do >something" to make this happen? ANSI? NBS? I would suggest talking to the chairperson of whichever ANSI committee handles VTP. To find out which committee, talk to the ANSI X3 Secretariat at the Computer and Business Equipment Manufacturers Association (CBEMA) in Washington, DC. The chairperson could shed light on the current state of the document and who the document editor is. The document editor will likely be the only person who could provide any machine-readable text, and the particular format is up to the editor (since ISO takes camera-ready hardcopy for publication and doesn't really care how it was generated).
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 16:18:34 GMT From: jqj@HOGG.CC.UOREGON.EDU To: comp.protocols.tcp-ip Subject: Re: telnet...
>From: braden@venera.isi.edu >There are Telnet controls (eg IP, AO, AYT...) that can appear at any time >in the stream, and a correct implementation must check for them. An >implementation that does not is not implementing the Telnet protocol >(RFC-764). This is precisely Bill's point. He argues that in some applications the higher level protocol knows that it will never generate or listen to such controls after a particular point in the session, and therefore could improve efficiency by saying "don't bother to check any more", but can't unless the Telnet protocol definition were changed. This seems to me to be one of many possible negotiable "performance options". One might also have negotiations that specified typical chunk sizes for transmissions (e.g. size of the Unix write() buffer. In no way related to MSS or anything like that, obviously) -- useful in helping the receiver do buffer management, expected average data rate, expected connection lifetime, ad nauseum. I don't believe that Telnet should implement any such negotiations because I see them all as minor performance tuning that greatly complicates the protocol. But I do think they should be considered as a group since they all share the characteristic that the applications protocol knows something about the stream traffic pattern that doesn't help the TCP level very much, but might help the remote applications level. Now, a LAT-like protocol that multiplexed several virtual terminal sessions (perhaps several telnet streams?) on a single sequenced packet protocol connection. THAT would be something to more seriously investigate as a standardized performance enhancement for connecting IP terminal servers to hosts.
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 17:01:58 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: Network Management Documents
As many of you know, two working groups of the Internet Engineering Task
Force have been working madly to finalize documents describing proposed
standards for network management in TCP-IP networks. These efforts are
a result of the recommendations in RFC 1052.
This note is to let you know that one of these two working groups,
the Management Information Base (MIB) Working Group, is about to report
two documents to the RFC editor. The first document describes the
structure of management information, how management data is structured
and represented in the MIB. The second document describes the required
management instrumentation of a TCP-IP system. It is expected that
these documents will eventually become Internet standards.
We are currently in the last stages of the comment period on the
documents. Comments can be sent to me (as WG chair) until *Wednesday
July 13th.* For those people interested in reviewing the documents, they
are available on-line by anonymous FTP:
Structure of Management Information:
at SRI-NIC.arpa: <ietf>idea0023-00.txt
Management Information Base
at NNSC.NSF.NET: pub/idea0024-01.txt
*PLEASE NOTE* that at this stage in the comment period we are only accepting
comments which help us clarify definitions. Unless you believe we have made
a truly gross technical error please do not suggest that we add additional
instrumentation or restructure the MIB.
Craig Partridge
Chair IETF MIB Working Group
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 17:42:41 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: Grist for someone's mill
If you send an ICMP echo request packet with IP Precedence = Flash Override and no IP TOS flag bits set, you back a reply with: Precedence = Routine from: vax.ftp.com Ultrix 2.0 gaak.lcs.mit.edu hacked 4.3bsd aim.rutgers.edu TWG VMS uunet.uu.net Sequent Balance sun.com SUNOS 4? Precedence = Flash Override from: xx.lcs.mit.edu TOPS-20 big-blue.lcs.mit.edu VM Wiscnet? ibm.com VM (IBM's 5798 FAL?) ucbvax.berkeley.edu 4.3bsd? Precedence = Flash Override & the Low Delay bit set from: oac.ucla.edu UCLA MVS James VanBokkelen FTP Software Inc.
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 17:52:35 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: flooded with routing updates?
In article <471@apctrc.UUCP> zgel05@apctrc.UUCP (George E. Lehmann) writes: >Tulsa, Oklahoma > >Has anyone else had problems with excessive routes showing up at their site? >On three occassions in the past thirty hours we have suddenly discovered >500-700 internet addresses in our Sun's route tables. >-- >George Lehmann, ...!uunet!apctrc!zgel05 One way to get lots of routes showing up in a host is to be on an Ethernet with several gateways that are connected to different regional or backbone networks. If you want to do robust routing, your host needs a route to each reachable net and that number is getting pretty large today. We have a jvnc-net router and an arpa-net router and we have hundreds of routes advertised by our jvnc-net router on a local Ethernet that has a few hosts on it (soon to be moved). Our arpa-net router is quiet, but the default, so we save advertising all the arpa-net routes. There is only one subnet with the external gateways on it, so there are only three routers that must keep these huge tables. Everyone else on campus can default to a router that is on that subnet. Kent England, Boston University
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 17:58:17 GMT From: streeter@NSIPO.ARC.NASA.GOV To: comp.protocols.tcp-ip Subject: mailing list
Please add my name to your distribution list. If there is an alternative
net address that this request should have gone to, sorry. This is the only
address I presently know of.
streeter@nsipo.arc.nasa.gov
Thanks, Roxanne
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 18:32:26 GMT From: jqj@HOGG.CC.UOREGON.EDU To: comp.protocols.tcp-ip Subject: default broadcast address
A typical situation for many of us is a subnetted class B network
running a variety of IP-based hosts, including many that are 4.3BSD and
4.2BSD based. In such an environment, one settable parameter on the
4.3BSD systems and others is the "broadcast address". There are many
possible values for this; I am curious what other sites set it to.
It is clearly desirable for all machines on a given subnet to agree on
the broadcast address. 4.xBSD generates ICMP errors or erroneosly
forwards Ethernet broadcasts with IP addresses it does not recognize as
IP broadcasts; even the latest Tahoe 4.3BSD code recognizes as IP
broadcasts only {net,0,0}, {net,subnet,0}, 255.255.255.255, 0.0.0.0,
and the set broadcast address (and not both {net,-1,-1} and
{net,subnet,-1} even though both are legal!). Earlier releases
recognize only a subset of these. By getting everybody to agree you'll
eliminate all those erroneous ICMP unreachables and ARP requests for
your subnet broadcast address. You might even avoid a serious
broadcast storm...
What is not clear is what in an imperfect world to try to get
everybody to agree to. Some possibilities:
{net,0,0} the 4.2BSD standard, and still the SunOS 4.0
default (according to "man ifconfig"). Some
people use this for backwards compatibility
with 4.2, but it is a violation of the IP spec
and 4.2 implementations are disappearing (right?).
{net,subnet,-1} i.e. the subnet broadcast address. The 4.3
Tahoe default if you set a subnet mask but no
broadcast address. Not too good if you plan to
change your subnet mask or if there is confusion
over what it is (e.g. if you're trying heterogenous
sized subnets).
{-1,-1,-1} i.e. the local broadcast address. Some IP
implementations insist on generating this address,
so it might also be a reasonable choice of standard.
{net,-1,-1} i.e. the network broadcast address. Has the
advantage of being immune to mis-set subnet mask
problems. But not a good choice if you have
routers that explode letter bombs and you want
broadcasts to be subnet-local.
In the past, I've standardized on {net,subnet,-1}. Charles Hedrick, the
first of us to have analyzed the broadcast storm problem, has in the past
recommended {net,0,0} as a concession to 4.2BSD [Chuck, am I taking your
name in vain?].
So, my questions: (1) What have other sites standardized on? (2) What
are the disadvantages, if any, of standardizing on the subnet broadcast
address?
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 20:08:17 GMT From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) To: comp.protocols.tcp-ip Subject: RFCs, ISO DISs and ASCII copies...
The trick is getting whoever has the machine-readable source for the text to create straight ASCII for public consumption (and of course the diagrams and such disappear). (I will no doubt get flamed, but...) There are obvious undeniable advantages to providing the RFCs, IDEAs, etc in ASCII line-printer-ready format. Yet there is also the need to express things that can't be described adequately or as concisely using just text. I think it is time that we move towards using a page description language for giving tables, state diagrams, etc. -Philip PS: Can anyone think of a language? :-)
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 21:05:28 GMT From: pwl@tc.fluke.COM (Paul Lutt) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Strange Network Traffic (Booting a Sun)
We recently purchased an Excelan LANalyzer board and Compaq PC for
analyzing our local ethernet. While familiarizing myself with this
test instrument, I decided to watch my Sun workstation (a diskless
Sun-3/60) boot single user. I'm seeing some interesting behavior that
I hope someone out in netland can explain. Here is the scenario:
======================================================================
1) The client workstation uses TFTP to boot the "boot" program.
(Everything looks reasonable so far.)
2) The boot program loads in vmunix through "nd" calls to the
server. (Still looks reasonable.)
3) Vmunix starts up. One of the first things it does is send out
a very strange looking ARP request:
Packet #1172: client -> ether-broadcast
ARP request (0.0.38.80 -> 0.0.38.80)
The source and destination internet addresses are totally bogus.
As expected, no ARP reply is ever received for this bogus request.
4) The client then sends a reverse ARP request to find out its own
internet address. The server replies with the correct information.
5) Now another funny packet. The client sends out a strange ARP
request:
Packet #1175 client -> ether-broadcast
ARP request (client -> client)
The client has just asked what its own ethernet address is! This
same request appears at least twice during the booting process.
======================================================================
Note that the workstation boots normally. I'm just curious why such
strange requests are being made.
As a side note, there was a recent posting in comp.sys.sun stating that
some nd error messages seen during booting are due to net mask traffic
directed at the booting workstation. I can confirm that this is
probably true.
During the booting sequence, the client sends a ICMP request for the
local net mask. In our case, all the systems on the network using
TCP/IP try to respond. Most systems start out by sending an ARP
request to the client to get its ethernet address so that they can then
send the mask. During the trace I ran, upwards of sixty systems sent
ARP requests, followed by ICMP replies containing the net mask. It
seems likely that such volumes of traffic directed at a workstation
might indeed exhaust the buffer pool.
Thanks to anyone who can shed some light on this. I sometimes think we
were better off NOT knowing what was going on deep in the bowels of the
network. :-)
--
Paul Lutt
Domain: pwl@tc.fluke.COM
Voice: +1 206 356 5059
UUCP: {uw-beaver,microsof,sun}!fluke!pwl
Snail: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA 98206
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 21:10:00 GMT From: DSMITH@OREGON.UOREGON.EDU (Dale Smith) To: comp.protocols.tcp-ip Subject: NI5210 in a Toshiba T3200?
I am getting ready to go out and buy a portable machine, a fast ethernet board, and FTP software's LANwatch to use as a network monitor for our campus network. The major question is, does anyone have any experience running the NI5210 in machines with a fast bus (12Mhz), and specifically, is there anyone out there running an NI5210 in the Toshiba T3200? Any comments on this proposed configuration are welcome. 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
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 21:34:34 GMT From: hom@sjsumcs.UUCP (Hom Bahmanyar) To: comp.protocols.tcp-ip Subject: A host sending an ARP request to itself?
We have an ethernet in our Math & Computer Science Department that has a
Sequent Balance, a Convergent Technologies Miniframe, and more than 50
PC compatibles on it. The Sequent and the PC's work perfectly on the
network (for example with PC-NFS); however, the Convergent machine has
some problems with the network: Commands such as telnet and ftp to or
from the Convergent machine always fail but other commands such as rwho
and ruptime from the Sequent show the Convergent host as being on the
network. Also the Convergent host never responds to pings from the
Sequent or the PC's. After we checked all the network setup files and
couldn't find anything wrong, I wrote a simple ethernet monitor program
for one of the PC's that receives all the packets directly from the PC's
3c501 ethernet controller and displays them on the screen. To my surprise,
I saw that the Convergent host was sending an ARP request about every 5
seconds to itself to resolve its own IP address. That is, in the ARP
packet there were:
sender's physical addr: Convergent host's ethernet addr
sender's IP addr: Convergent host's IP addr
target's physical addr: 0 0 0 0 0 0
target's IP addr: Convergent host's IP addr
But why would the Convergent host want to resolve its own address when
it already knows its ethernet address?
Any help you can give me on this will be greatly appreciated.
----
Hom Bahmanyar (408) 924-5107
San Jose State University, Math & Computer Science Department
San Jose, CA 95192-0103
...!{sun,ames,pyramid,hplabs}!sjsumcs!hom
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 22:20:22 GMT From: brescia@PARK-STREET.BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: Re: telnet...
A "DON'T TELNET ANYMORE" option can save you a whole lot on efficiency.
Yes, making a direct path from the net driver to the terminal driver is much
more efficient. You do need the escape route however. 10 years ago (or was
that when it was done in ITS) there was talk of having the telnet server throw
such a switch, which meant "pass everything transparently between terminal and
net until you see a special character". That would be IAC in the direction of
net->term and one of BREAKSET in the term->net direction. Once the escape
character was encountered the server would have to interpret again, until it
was satisfied to put the path in transparent mode again.
If there was a way to make sure that no more telnet options processing
would need to be done, a similar thing could be done with telnet on
other operating systems, saving 2 process-switches per character.
Since there is always option processing going on, you just invoke the server
for the characters it needs to handle. IAC-IAC doubling would be expensive,
but how often do you transfer the character 0xFF?
Regards,
Mike
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 22:33:59 GMT From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) To: comp.protocols.tcp-ip Subject: Re: Are there IP-over-PDN X.25 implementations on SunLink X.25?
Yes, in a nutshell. The method for transmitting IP packets over X.25 requires: (a) the User Data field in the Call request contains 0xCC as the first octet and (b) the IP datagrams be sent over the VC aligned on packet boundaries, with packets greater than the maximum X.25 PDU being sent as complete-packet-sequences (ie. M bit on for all but the last packet of the seq). We use an ACC X.25 card to do this, and we speak to the original X25net hardware, which is an Interactive Systems (INcard). I have heard of people using the SUNlink X.25 S/W (in PDN, *not* DDN mode) with success. In fact, SUN has their own internal internet spanning North America and parts of Europe/Japan using IP over X.25. For more information, contact your SUN rep. As for the Comer/Korb paper, it was published by CSNet. It is available via anonymous FTP from sh.cs.net, as the file "dn5" (or something like that). I can mail it to you if you need it. Hope this helps, -Philip
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 88 23:32:08 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: TCP support for Precedence
Wanted: Non-omnicompitent, non-omniscient TCP enhancer with newly-developed TCP support for IP Precedence seeks another sophisticated real-world implementation for testing, object: Negotiating a connection at Flash Override or even higher. Ability to speak IP Security (Old, Basic and/or Extended) a plus. Testing against my own code only (poking around the Internet hasn't yet turned up a host that that will do this) lacks a certain satisfaction. If there were any Multices left, I would try there first, but alas... James VanBokkelen FTP Software Inc. jbvb@vax.ftp.com (617) 868-4878
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 88 01:26:31 GMT From: henry@utzoo.uucp (Henry Spencer) To: comp.protocols.tcp-ip Subject: review of Comer TCP/IP book
I acquired a copy of "Internetworking with TCP/IP" at Usenix and finished
reading it on assorted airplanes. I have sufficiently mixed feelings
about it that I think it worthwhile to review it in detail.
Background: I'm not a real TCP/IP guru, but might qualify as an apprentice
guru. I learned about it originally by reading the RFCs (gak) and I work
on and maintain our local version, a variant of the KA9Q implementation.
I can't claim to be intimately familiar with all the details or to have
read the whole Protocol Handbook, but I know the outlines of most of it
and have combat experience with some of it.
The book emphasizes overall understanding of the protocols, although it
does cover a fair amount of detail. The really fine points are punted to
the RFCs, for the most part. It is meant to be useful as both a textbook
and a reference book, and generally strikes a happy medium. It contains
coherent discussions of a number of issues that are hard to find in one
place otherwise. Its appendix of implementation hints is worth the price
of the book all by itself, if you're going to be implementing TCP/IP. It
is competently produced, with few botches (although some that remain are
serious, e.g. errors in RFC numbers in some of the Further-Reading sections
and a disastrous typo in Figure 4.1, the ONLY place where the decoding of
Internet addresses is explained precisely).
I wish I could recommend this book unreservedly. Alas, I can't.
The fact is, this book has serious flaws. First, most serious, and quite
possibly the cause of the others, is that it appears to have been put
together hastily as an expansion of a knowledgeable professor's skeletal
lecture notes. The result is that while individual sections are okay,
they are not tied together well. In particular, there are many cases
where something is referred to as if it had already been explained, when
in fact the explanation comes later or is entirely missing. The appendix
on the Berkeley interface refers offhandedly to the fact that a connection
is characterized by both its endpoints, and hence more than one connection
can be active on the same port -- but this important and subtle concept is
NEVER discussed in the text proper! The discussion of the name server
protocol suddenly starts using variable-length strings without explaining
how they are encoded... that comes later, in the section on the compressed
name format! The chapter on ARP never does explain the PROTOCOL field.
These are not isolated examples; this sort of thing happens continually,
and makes the book very frustrating to read sequentially. I already knew
enough to make this only an aggravating nuisance; a real novice would, I
think, find it very troublesome without external help.
Okay, so this hurts it as a textbook. Is it useful as a reference book?
Same answer: yes and no. The trouble with it as a reference book is that
too many details are left out. There are several references to the Karn
algorithm for RTT estimation, but it is never discussed; describing it
precisely and giving an outline of why it's good would take only a page
or two. The three-way handshake for TCP connection establishment is
explained, but the handshaking for closing a connection is never really
explained; the state diagram from RFC 793 would take only a couple of
pages to show and tersely explain, but this is never done. The urgent
pointer is brushed off in one sentence that does not really explain how
it works. While it isn't really realistic to expect a book of this size
to replace the Protocol Handbook, this book would be an order of magnitude
more useful as a reference if it included 10% more detail.
A lesser, related problem is inconsistent level of detail. The lower-
level protocols are explained in considerable detail, while the high-level
ones are crowded into a chapter or two that permits only a hint at the
overall flavor of a few of them. The level of detail is inconsistent
even within discussions, with detailed message formats sometimes given
and then accorded only a quick hand-waving explanation.
One last annoyance in using the book as a reference is that the textbook-
oriented exercises at the end of each chapter sometimes raise important
points that one would hope a reference book would discuss more explicitly.
The implementation-hints appendix resolves some, but not all, of these
loose ends.
Overall, this book would be acceptable as a textbook for a course taught
by a knowledgeable professor who can fill in the gaps and smooth down the
rough edges, or as a self-study text for a bright student who knows
something about the topic already and has access to a copy of the Protocol
Handbook. I cannot recommend it for self-study in general, and as a
reference its usefulness is limited. It seems to me that many of the
problems arise from it being prepared in haste. I would look forward
eagerly to a second edition, slightly expanded, thoroughly revised for
completeness, coherence, and consistency, and preferably tested on an
unassisted novice before publication. That second edition could be a
truly superb first book on TCP/IP; the first edition is rather mediocre,
and is the clear choice only because there is no other. It's really
unfortunate that the publishers are succumbing to the computer builders'
bad habit of letting their customers debug their products.
All that being said, this book *is* a lot better than nothing. I learned
quite a bit from it, despite the problems. If you are considering buying
it, either for yourself or a course, I would say "go ahead... cautiously".
--
| Henry Spencer @ U of Toronto Zoology
| {ihnp4,decvax,uunet!mnetor}!utzoo!henry
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 88 09:37:41 PDT From: braden@venera.isi.edu To: kwe@bu-cs.bu.edu, tcp-ip@sri-nic.arpa Subject: Re: flooded with routing updates?
One way to get lots of routes showing up in a host is to be on an Ethernet with several gateways that are connected to different regional or backbone networks. If you want to do robust routing, your host needs a route to each reachable net and that number is getting pretty large today. This is not a requirement for "robust routing." An Internet host should only need to know a few default gateways, and take Redirects to find out about the others. This is just another example why hosts wiretapping gateway IGP's is not a part of the Internet architecture, and is often a bad idea. Bob Braden
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 88 03:42:53 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Strange Network Traffic (Booting a Sun)
In at least some versions of the Sun software, the systems ended up using an Internet address that was their system serial number. This was done during early stages of kernel operation, before the system knew its Internet address. Typically the serial numbers were small, so you'd get an address that looked like 0.0.x.y. In some releases, this entry was never removed from the routing table. Once the system came up, it was interpreted as a default route. I'm not sure whether these things are still happening under current releases. This is a moderately dangerous practice. 0.0.x.y should be interepreted as meaning "this net, host x.y". It is certainly possible that there could already be an x.y on the current network. I'd be very surprised if this practice continued into release 4.0
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 88 03:53:25 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: telnet...
Unfortunately Mark is for once giving Unix more credit than it is due. Berkeley's TCP/IP includes a telnetd that runs as a user process. It reads characters from a net connection and copies them into a pty, and visa versa for the echo. There is kernel support available that makes this unnecessary, but as far as I know, the only vendor that has decided to distribute this code is Pyramid (and it isn't released yet). This makes an enormous difference to responsiveness of a telnet connection on a heavily loaded machine. So it's worth doing on our Pyramid timesharing systems. It has not seemed necessary for our other systems (primarily Suns), which are either single-user or have only a few users. In my opinion the best implementation (which is what our Unix code does) is a combination of the two approaches. There is a telnet daemon. It is used to do connection opening and closing and handles all option and control sequence processing. It uses an ioctl to crosspatch the network to the pty. The kernel then handles passing characters as long as they are "easy". When it detects an IAC from the network (the beginning of a telnet option of some sort), the crosspatch is broken and control returns to the daemon. Thus the kernel handles the normal case, for which performance is important, but need not be complicated by negotiations, etc. This code is available, but so far no one has reported success in getting it to run on machines other than the Pyramid and some other unnamed system which I assume is not a VAX. A number of people have taken copies of it and not told me the results. I'd be happy to send it to you, but only if you are serious about doing the kernel work necessary to get it to work, and telling me the results.
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 Jul 88 09:27:14 EDT From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: Re: ISO VTP
>Anyway we don't want the standard ISO documents on-line. They're >incomprehensible (except for the CLN documents which are nice). What >we want is a description of the protocols that us or