|
|
ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for August 1988 (307 messages, 170694 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Aug 88 09:40:57 PDT From: lars@ACC-SB-UNIX.ARPA (Lars J Poulsen) To: lars@ACC-SB-UNIX.ARPA, tcp-ip@sri-nic.arpa
To: tcp-ip@sri-nic.arpa Date: Mon, 1 Aug 88 08:44:14 PDT From: lars (Lars J Poulsen) Message-Id: <8808011544.AA13705@ACC-SB-UNIX.ARPA> Subject: Re: TCP/IP over X.25 under Unix ? (really: those damn cc-lines) Sorry; along with Keith McCloughrie I confess to problems with editing cc-lines, thus letting you all read a personal reply (Though the damage may have been limited since it was in a furreign tongue). / Lars Poulsen
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Mon, 01 Aug 88 15:44:50 EDT From: Doug Greenwald <R1ECGF%AKRONVM.BITNET@CUNYVM.CUNY.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: HP TCP/IP Conformance
Hi, A few weeks ago, i saw something mentioned concerning problems with HP systems with TCP/IP. Something about problems getting HP's to work with various gateways. I would appreciate seeing this info again. We are currently looking at various vendors for networkable workstations, an HP is one of the contenders, if you or they can show us that thier workstations support TCP/IP and/or Ethernet networking with minimal 'adjustments'. Please respond directly to me and I will sumarize to the net if there is sufficient interest. Doug Greenwald Engineering Computer Graphics Facility University of Akron Bitnet: R1ECGF@AKRONVM
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 11:53:33 GMT From: gregb@dowjone.UUCP (Greg_Baber) To: comp.protocols.tcp-ip Subject: Re: Instrumenting a TCP Implementation
In article <8807291003.AA24101@ucbvax.berkeley.edu> kzm@TWG.COM (Keith McCloghrie) writes: [stuff eaten] >> We, at the Department of Computer Science, University of Maryland, have >> done an instrumentation of TCP/IP. Here is the abstract from the >> Technical Report describing our work: >> "We .... >> ... code)." >> Interested persons can get a copy of the Report by sending mail to >> tcplog@chakra.cs.umd.edu >> Please quote the following numbers in your request: >> CS-TR 2063 and UMIACS-TR 88-50 Interested! Please send me the reports too. >Thank-you, >Keith. -- Reply to: Gregory S. Baber Voice: (609) 520-5077 Dow Jones & Co., Inc. E-mail: ..princeton!dowjone!gregb Box 300 Princeton, New Jersey 08543-0300
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 18:07:00 EDT From: <enger@gburg.scc.com> To: "geoff" <geoff@usafa.arpa> Cc: <tcp-ip@sri-nic.arpa> Subject: VMS TCP/IP software
Geoff: I will have to concur that Wollongong is expensive, but to some extent you get what you pay for. Those guys send engineers to all the networking conferences. TWG seems to be incorporating some of the more important protocol enhancements into their products in a timely fashion. Their version 3.2 software incorporates the Van Jacobson window adjustment scheme. We use version 3.2 and are pretty happy with it. When all I can find to complain about is CC: fields in the mailer (and thats a VMSmail problem really) it can't be too bad a product, right? The capability to keep up the with latest developments may become increasingly important. The ability to respond to Usage Sensitive Charging by incorporating a more efficient telnet may be a big win to your budget. If you use the TWG package to connect to the wide area subnet you may appreciate their support when BBN womps PSN 7.0 on you :-) . Although I am not a user of the product, I have heard generally good reports on the Multinet product. This product was (maybe still is) available from SRI. I believe two of its developers have left SRI to persue the further developement and enhancement of the product. You may wish to review the recent TCP/IP archives to locate them. Good luck in your quest, Bob Enger Contel Federal Systems
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 15:37:43 GMT From: eckert@faui10.uucp (Toerless Eckert) To: comp.sources.wanted,comp.unix.wizards,comp.unix.questions,comp.protocols.tcp-ip Subject: Again: looking for gated
I looking for the sources of gated. As i do not have access to the internet, i cannot get them through ftp. I only have access to bitnet and uucp. I also could get files using anonymous ftam over the PSN. Is there any bitnet listserver that has gated, or can someone send me the sources by mail ? Toerless Eckert (tte@derrze0.bitnet)
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 18:41:35 GMT From: geoff@USAFA.ARPA (Capt Geoff Mulligan) To: comp.protocols.tcp-ip Subject: VMS TCP/IP software news
We have a number of VAXen connected via an ethernet and would like to get them talking to our tcp/ip systems Do you have any pricing information yet and what about government or educational discounts? We presently have Wollongong's software running on one of our systems and I am not satisfied with it; plus it is so expensive. geoff
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 19:29:01 GMT From: bobn@ism780c.isc.com (Robert Noh) To: comp.protocols.tcp-ip,comp.os.vms Subject: TCP/IP on VMS 5.0
Is there any implementation of TCP/IP that is ready to go
on VMS 5.0? Or, is there an implementation that is
due to be released "real soon, now?"
(Rumor has it that SRI's Multinet runs on 5.0. Can anyone
confirm this?)
On a related note, does anyone have a list of TCP/IP implementations
that run on a multiprocessor machine? This is more for a reference
than anything else, but I still would like the information.
Thanks in advance. Post or mail your replies to me. Any
mail responses will be summarized to the net.
Robert Noh {sdcrdcf|attunix|microsoft|sfmin}!ism780c!bobn
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 19:44:50 GMT From: R1ECGF@AKRONVM.BITNET (Doug Greenwald) To: comp.protocols.tcp-ip Subject: HP TCP/IP Conformance
Hi, A few weeks ago, i saw something mentioned concerning problems with HP systems with TCP/IP. Something about problems getting HP's to work with various gateways. I would appreciate seeing this info again. We are currently looking at various vendors for networkable workstations, an HP is one of the contenders, if you or they can show us that thier workstations support TCP/IP and/or Ethernet networking with minimal 'adjustments'. Please respond directly to me and I will sumarize to the net if there is sufficient interest. Doug Greenwald Engineering Computer Graphics Facility University of Akron Bitnet: R1ECGF@AKRONVM
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 20:14:11 GMT From: Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin) To: comp.protocols.tcp-ip Subject: Can anyone help this guy?
Hi, I got this note from a friend of mine in Tokyo (edited to remove unnecessary text). Can anyone help him out? Thanks, -- Mark Date: Mon 1 Aug 88 21:42:37 From: ken-ichiro murakami <MURAKAMI@NTT-20.NTT.JP> Subject: Proxy ARP on SUN Mark, I have a question about Proxy ARP. My colligue in Tohoku University wants to use Proxy ARP on SUN. As far as I know, there are two Proxy ARP software. One is developed in U-texas and the other is developed by Barry Shein(bzs@bu-cs.bu.edut). I've alreay seni, I got this note from a friend of mine in Tokyo (edited to remove unnecessary text). Can anyone help him out? Thanks, -- Mark Date: Mon 1 Aug 88 21:42:37 From: ken-ichiro murakami <MURAKAMI@NTT-20.NTT.JP> Subject: Proxy ARP on SUN Mark, I have a question about Proxy ARP. My colligue in Tohoku University wants to use Proxy ARP on SUN. As far as I know, there are two Proxy ARP software
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 21:05:55 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Furreign tongue
Lars: Dansk is not necessarily a furreign tonque--my basic problem was the communications software for my PC at home does not provide immediate interpretation of the european character sets. The most made out of your discussion was that support for the ACP6250 was provided and available from some vendor in Stockholm. Merton
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 21:16:57 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: TCP/IP over X.25 under Unix ?
Lars: My CIT224 seems to be brain-damaged. Is the "}" the "a" with the "o" on top and the "|" a "o" with a "/"? These were the only characters that wouldn't translate correctly. Merton
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 22:07:00 GMT From: enger@BLUTO.SCC.COM To: comp.protocols.tcp-ip Subject: VMS TCP/IP software
Geoff: I will have to concur that Wollongong is expensive, but to some extent you get what you pay for. Those guys send engineers to all the networking conferences. TWG seems to be incorporating some of the more important protocol enhancements into their products in a timely fashion. Their version 3.2 software incorporates the Van Jacobson window adjustment scheme. We use version 3.2 and are pretty happy with it. When all I can find to complain about is CC: fields in the mailer (and thats a VMSmail problem really) it can't be too bad a product, right? The capability to keep up the with latest developments may become increasingly important. The ability to respond to Usage Sensitive Charging by incorporating a more efficient telnet may be a big win to your budget. If you use the TWG package to connect to the wide area subnet you may appreciate their support when BBN womps PSN 7.0 on you :-) . Although I am not a user of the product, I have heard generally good reports on the Multinet product. This product was (maybe still is) available from SRI. I believe two of its developers have left SRI to persue the further developement and enhancement of the product. You may wish to review the recent TCP/IP archives to locate them. Good luck in your quest, Bob Enger Contel Federal Systems
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 1 Aug 88 23:25:49 GMT From: microsoft!jonsm@beaver.cs.washington.edu (Jon Smirl) To: tcp-ip@sri-nic.arpa Subject: Re: Microsoft MAC/Vector interface
| 1. You do all of your binding (setting up handlers for incoming packets) | at CONFIG.SYS time, so you can't use many DOS (or OS/2) services while | starting your protocol modules. At OS/2 config.sys time a driver can actually do an awful lot *more* than it can after config.sys time. This is because it is running at ring 3 at that time and can do file i/o for example. After init, all driver code is ring 0 and can't do any os services except devhlps. If the above remark is really about wanting to write protocol code to live at ring 3, this can actually be done within the present structure--see the response to point 2 below. Note that we will in the future be extending the protocol manager to add dynamic binding and unbinding. The current bind command logically can do that today; all that is missing is the unbind command and a way to ask the protocol manager to issue a binds and unbinds at run time. In fact, the version 2 protocol manager spec will allow for several run time functions, including dynamic binding, unbinding, and query/change module config settings. Ring 3 APIs to the protocol manager will let applications invoke these services. | | 2. You cannot un-bind, ever. No transient network protocols built into | programs, no un-loadable protocol TSRs. Instead, you have to edit a file | & reboot if you need more memory to run your CAD program or whatever.... See note about our planned bind/unbind extensions above. Regarding transient protocols--on OS/2 you can do this by writing a stub protocol module that interfaces to a ring 3 protocol daemon. The daemon would ioctl threads down to the stub to get requests and pass back responses--or better, ioctl down the address of a shared memory area where request queues could be managed between ring 0 and 3. A similar thing could be done on DOS 3. Regarding unloading TSRs--again using the stub protocol module, you could bring in the actual protocol code as an EXE which certainly could terminate and free its memory. Regarding "editing a file" to reconfig: there is no requirement for a module to take its config from protocol.ini, or to do it only at boot time. Modules can use private means to get config, including doing it dynamically at run time via ioctls to the driver or whatever. Modules can be written to even resize themselves when run time reconfig happens--ie, if they dynamically allocate their buffer space, or have an app-level daemon do this for them. (All this is saying is that if you are creative you can even get the effect of dynamic reconfig sooner than when we provide a standardized way for doing it). | | 3. Rather than telling MAC/Vector what kind of packets you want, instead | it goes down its list of handlers, asking them one after another "do you | want this packet". This means that there is no possibility of arbitration | (or even error detection) when two applications want the same type, and | opens the door for "badly behaved applications" to screw things up for | the rest of us. | We considered providing a way to provide packet dispatch info to the vector, but providing adequate flexibility here was far more complexity and overhead than seemed justified by the need. What does it mean to tell it "what kind of packet you want"--do you specify what the source address should be, or destination SAP, or both, or some bit masked address compare, or do you also want to include specific packet command codes, or protocol type bytes, or other compare conditions, or what? Cases can be made for all these and more, and that just leads to absurd complexity for a little-needed function. In general it is a "configuration error" to have two drivers installed that would conflict over what packets they want; indeed, all that a complex descriptor mechanism would do is let you detect this configuration error. That would be nicer than not detecting it, but again, the amount of overhead to detect this rather unusual error condition did not appear justified. The current polling scheme works just fine for what we believe the 99% case to be--protocols sharing a mac where the conflicts don't arise. We are interested in any concrete suggestions on what a better solution would be, or why there is some important need not addressed by the current solution. microsoft!jonsm
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 88 00:07:46 GMT From: Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin) To: comp.protocols.tcp-ip Subject: Proxy ARP question
It appears that my message got damaged on the way out. Anyway, MURAKAMI@NTT-20.NTT.JP (or %NTT-20.NTT.JP@RELAY.CS.NET) is trying to get ahold of software that supports Proxy ARP and is having problems. He isn't directly on the Internet. Can anyone help him? -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 88 13:36:48 GMT From: roy@phri.UUCP (Roy Smith) To: comp.protocols.tcp-ip Subject: Re: How many people receive TCP-IP
enger@GBURG.SCC.COM writes:
> An easy way to get a start at the determination is to look at the main
> distribution list at the NIC. [...] some of those direct recipients are
> mail exploders. [...] perform the above process iteratively to get some
> idea of the ultimate number of recipients.
And then, don't forget to add in all the people who read TCP-IP as
its usenet alter ego, comp.protocols.tc-ip. The most recent stats from
Brian Reid (which somehow I missed the first time around, for no reason
that I can explain) estimate that something like 9800 people see this
material in that forum. My guess is that that far outweighs the count of
people who are on the mailing list, either directly or via mail exploders.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 88 14:08:48 GMT From: root@sbcs.sunysb.edu (root) To: comp.protocols.tcp-ip Subject: BOOTP vendor support
I am in the midst of implementing network bootstrap code for our Amiga NFS product. I have the new Sun bootparams bootstrapper stuff going, but it seems to fall short of what is really needed. In particular we're a bit worried that Sun requires use of RARP in bootstrapping and that casual perusal of vendor glossies shows not much support for RARP by vendors other than Sun (and NFS licensees). BOOTP seems to be a whole notch better in the sense that it is a simpler protocol, it supplies HDW -> Internet address translation without using RARP, and using the vendor specific field (RFC-1048) seems to provide everything a booting machine needs eg subnet mask, UTC time offset, name server locn, etc. Since BOOTP doesn't use RARP we can provide portable source to our customers who do not have it. Now, the question: who else is/will support BOOTP? The only other vendor I've seen supporting BOOTP is SGI. Is BOOTP a dead end in light of Sun ASI, etc? While I've got your attention, is anyone aware of any efforts towards automating IP address generation? It would seem a natural extentsion to either RARP or BOOTP, modulo the usual database consistency problems. Rick Spanbauer Ameristar
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 88 15:48:30 GMT From: rochester!srs!dan@bbn.com (Dan Kegel) To: tcp-ip@sri-nic.arpa Subject: TCP/IP and NFS for MacOS?
I'm asking this on behalf of a friend at a large defense contractor, who doesn't have internet access (but does have lots of pretty missiles and guns). He'd like to use his Unix boxes as file and CPU servers, and use a mix of Mac SE and Mac 2 boxes as clients; Ethernet would be use to connect everything. We think there is an Ethernet card for the SE, so that's not a problem. The question is software. We know about TOPS; however, it hasn't yet been ported to his particular Unix box. Can anybody suggest TCP/IP and (oh, please) NFS (that's Sun's Network File System) packages that run under the Mac OS? Or any other networking alternatives? Please reply by e-mail, and I'll summarize. Thanks... -- Dan Kegel "We had to get it passed before the columnists attacked!" srs!dan@cs.rochester.edu rochester!srs!dan dan%srs.uucp@harvard.harvard.edu
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 88 18:56:03 GMT From: jch@CHUMLEY.TN.CORNELL.EDU (Jeffrey C Honig) To: comp.protocols.tcp-ip Subject: Re: Again: looking for gated
Gated is available for annonymous FTP from devvax.tn.cornell.edu as pub/gated/gated.tar.Z. Gated is available via electronic mail by sending mail to gated-people-archive@devvax.tn.cornell.edu with a subject line of get gated.tar.* Several pieces of mail will be sent to you which comprise a split, uuencoded, compressed tar file. Questions and experiences relating to gated may be sent to the gated mailing list, gated-people@devvax.tn.cornell.edu. Requests for addition to the list should be sent to gated-people-request@devvax.tn.cornell.edu. Jeff
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Aug 88 21:59:26 GMT From: henry@utzoo.uucp (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: a proposed modification to ARP
In article <19880727152537.7.DCP@SWAN.SCRC.Symbolics.COM> DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) writes: >... Networks >are a LOT LOT bigger and broadcasts are on people's mind, whether it's a >real problem or not. Actually, it has always seemed to me that ARP -- the mapping between physical addresses and logical ones, so to speak -- was the one place where use of local broadcast was proper and defensible. I personally would put ARP last on the list of broadcast problems to be fixed, and a number of other things much higher. I have trouble believing that ARP by itself, if it were the only use of broadcast, would be a real problem. Is it really so? -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 00:43:25 GMT From: bdale@hpcsrc.HP.COM (Bdale Garbee) To: comp.protocols.tcp-ip Subject: Re: a proposed modification to ARP
>Let's also remember that ARP runs on 5 networks other than Ethernet >(Experimental Ethernet, AX.25, ProNET, Chaosnet, and ARCNET) Not to mention Amateur Radio AX.25 ala the KA9Q package.
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 10:57:40 GMT From: DEDOUREK%UNB.CA@CORNELLC.CCS.CORNELL.EDU To: comp.protocols.tcp-ip Subject: Re: Re: How many people receive TCP-IP
> enger@GBURG.SCC.COM writes: > > An easy way to get a start at the determination is to look at the > main > distribution list at the NIC. [...] some of those direct > > And then, don't forget to add in all the people who read TCP-IP as > its usenet alter ego, comp.protocols.tc-ip. The most recent stats Ditto the BITNET LISTSERV service. John DeDourek, University of New Brunswick, Fredericton, N.B. Canada dedourek@unb.ca (dedourek@unb.bitnet)
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 13:44:39 GMT From: dd@sei.cmu.edu (Dennis Doubleday) To: comp.protocols.tcp-ip Subject: Question about TCP/IP on VMS
I currently have an application running on Ultrix which uses TCP/IP. Each machine in the network has a server running on it. The server is opened in passive mode and listens at a known port for traffic. Under Ultrix this "known port" is defined by adding an entry for my server into the file /etc/services. How is this done under VMS? How are the well-known ports defined? Or does this depend on the TCP/IP software you have?
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 15:22:51 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: Microsoft MAC/Vector interface
The message from microsoft!jonsm was presumably a mis-posting, since it replied to something I had said on pcip@udel.edu (comp.protocols.tcp-ip.ibmpc). Unless people are interested, I won't debate DOS & OS/2 arcana here. James VanBokkelen FTP Software Inc.
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 16:25:54 GMT From: mark@cbnews.ATT.COM (Mark Horton) To: comp.protocols.tcp-ip Subject: Re: ACSNET Access
In article <644@stcns3.stc.oz> dave@stcns3.stc.oz (Dave Horsfall) writes: >Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz What I don't understand is why some Australians advertise their addresses as dave@stcns3.stc.oz, as shown in the From: line and the signature of the referenced article. .oz is NOT an official domain, while .oz.au IS. The UUCP map does list .oz and knows how to get to it. This puts .oz up there with the other "semi-official" domains like .uucp, .bitnet, .cdn, and the like. People routing via UUCP can get to them, but people using some other incarnation of the domain system, especially TCP/IP, cannot. Posting to a worldwide computer network with an incomplete domain name is like giving your phone number and forgetting the country code. It might work locally, but it doesn't necessarily work in some other country. Please encourage other Australians to use the full name .oz.au on their domain style addresses, unless they are really sure that the context is specific to ACSNET. >dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave This stuff looks fine, although both are kludges to get around various limitations when you're trying to say dave@stcns3.stc.OZ.AU . If this form doesn't work, then something is broken somewhere (or maybe the person you're sending to just doesn't answer their mail.) Mark
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 16:44:35 GMT From: dennis@rlgvax.UUCP (Dennis.Bednar) To: comp.protocols.tcp-ip Subject: subnet IP mask stored in route or interface struct?
Does 4.3BSD store the IP subnet mask in the route structure
(struct rtentry) or the interface structure (struct ifnet)?
The reason I ask, is that RFC 950 suggests that it be stored
on a per interface basis. However, I have found a particular
case (described below), in which it is better to store the mask
on a per route basis. Perhaps the example I have contrived
violates an unmentioned assumption that subnets in the same
network should be adjacent.
In the figure below, the ---- lines represent a single physical
ethernet cable. Gw1, and gw2 stand for gateway 1 and gateway 2.
Both gw1 and gw2 below have multi-homed IP addresses (that is two
separate home addresses, one for each network connection).
In the figure below, subnet1 and subnet2 (in the same network)
are separated apart by a different network, consisting of just
a single subnet. Subnet 1 and 2 below are class C network addresses
containing 3 bytes of <network-number>, and 4 bits for the <subnet-number>.
The network in the middle is a class B network composed of 2 bytes
of <network-number>, and 4 bits for the <subnet-number>.
gw1 gw2
-------------------- ------------ ------------------
Name subnet1 network subnet2
Number 192.7.8.0x10 128.5.0x10 192.7.8.0x20
IPmask 255.255.255.0xf0 255.255.0xf0.0 255.255.255.0xf0
The problem with using the IP mask for an interface is that
gw2 above will have trouble forwarding packets destined for hosts
in subnet1. Suppose there is packet destined for host
192.7.8.0x11. I will show the problem after giving some
background information.
------ Begin of some background information:
There is presumed to be 3 tables of routing table structures
containing
<destination, gateway, flags, interface-ptr>.
These 3 tables are the host routing table, the subnet routing
table, and the network routing table. Destination is the
IP address of a host (if in host routing table), of a subnet
(if in subnet routing table), or of a network (if in netowrk
routing table). The flag indicates if the route is direct (ie
through a local gateway or the home machine) or indirect thru
a remote gateway (ie the flag is used instead of the
recommended algorithm described in RFC950 to decide if the
packet should be sent directly or thru a gateway). The interface
pointed to by interface-ptr is presumed to contain (at a minimum):
< my_ip_addr, my_ip_mask>
The 3 tables are searched in this order: host, subnet, network, using
the dg.ip_dest as a key into the route.destination field. For a
host table search, all 4-bytes are compared. The subnet table search
is described separately below. The network table search compares
ip_network_of(dg.ip_dest) with route.destination. The search stops
when a route has been found. The subnet table search is this:
for each subnet routing table entry
if (route.dest == (dg.ip_dest & route.interface.my_ip_mask))
{
found = routing table entry;
break; /* stop table search */
}
Once the route has been found, the route.flag tells whether to send
directly or through a gateway, as opposed to the recommended algorithm
described in RFC950.
---- end of background information
Now here is the problem: the subnet table search on gw2 above will
fail to locate the route entry in its subnet table, because the ip_mask
will strip off too many bits (2.5 bytes) causing the compare of
route.destination in the subnet table to fail:
if (192.7.8.0x10 == (192.7.8.0x11 & 255.255.0xf0.0))
if (192.7.8.0x10 == (192.7.0.0))
I would like to point out that by storing an IP mask on a per route
basis, this problem would go away, since the IP mask would be correct
for the destination subnet, which is remote to this particular network.
I would appreciate any comments on this matter.
--
FullName: Dennis Bednar
UUCP: {uunet|sundc}!rlgvax!dennis
USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone: +1 703 648 3300
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 16:58:07 GMT From: sow@eru.mt.luth.se (Sven-Ove Westberg) To: comp.sources.wanted,comp.protocols.tcp-ip Subject: Whois sources.
I would be very pleased to know where I could get programs
to Unix for the tcp/whois protocol and database?
Regards,
Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Tel: +46-920-91677 (work) +46-920-48390 (home)
UUCP: {uunet,mcvax}!enea!cad.luth.se!sow
ARPA: sow%cad.luth.se@ucbvax.berkeley.edu (only dumb ARPA mailers)
Internet: sow@cad.luth.se
Bitnet: sow%cad.luth.se@sekth
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 17:25:32 GMT From: wunder@SDE.HP.COM (Walter Underwood) To: comp.protocols.tcp-ip Subject: Re: HP TCP/IP Conformance
A few weeks ago, i saw something mentioned concerning problems with HP systems with TCP/IP. ... We are currently looking at various vendors for networkable workstations, an HP is one of the contenders, if you or they can show us that their workstations support TCP/IP and/or Ethernet networking with minimal 'adjustments'. I think this is worth answering to the whole list. HP's Unix machines do implement a full TCP/IP, and do work with other systems. The networking is based on 4.2 BSD, and will be upgraded to use the Van Jacobson algorithms at the earliest possible time. [The Unix boxes are the HP9000 Series 300 (68000-based) and HP9000 Series 800 (RISC-based). HP's name for their Unix OS is HP-UX.] The HP3000 minicomputers (runnning MPE) use a limited version of the TCP/IP protocols. They do not support UDP, use real 802.3 instead of Ethernet, and use HP Probe instead of ARP. HP is working on Ethernet and ARP for the HP3000. The HP3000 uses proprietary login and file transfer protocols. Regular ARPA services (Telnet, FTP, and SMTP) are available from The Wollongong Group. The HP1000 runs a TCP/IP which is similar to the HP3000, but the 1000 already support Ethernet, I believe. If you have MPE systems, you need a gateway that talks 802.3 and Probe. The only gateways that do that are the HP9000 series 300 and series 800 machines (HP-UX), and boxes from cisco Systems, Inc. Walter Underwood HP Software Engineering Systems Palo Alto, CA PS: HP-UX can set Precedence and Security on TCP connections. Anybody wanna try it?
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 17:29:04 GMT From: deke@valhalla.ee.rochester.edu To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Status of NTP?
What is the status of NTP? I have rfc958, is this the most (and only) relevant document? I would like to keep 35 or so machines on my networks time-synched *with eachother*..... having that common time be "correct" is icing on the cake. Up till now I have tried using 4.[23]BSD timed and /usr/ucb/rdate on UN*X machines, and they work fine, but I certainly wouldn't mind using a more elegant method. - Deke Kassabian ------------------------------------------------------------------------------- \ deke@ee.rochester.edu "Experience is something you don't / \ or ...!rochester!ur-valhalla!deke get until just after you need it." / \-----------------------------------------------------------------------------/
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 17:47:27 GMT From: ted@ultra.UUCP (Ted Schroeder) To: comp.protocols.tcp-ip Subject: Re: How many people receive TCP-IP
enger@GBURG.SCC.COM writes:
> An easy way to get a start at the determination is to look at the main
> distribution list at the NIC. [...] some of those direct recipients are
> mail exploders. [...] perform the above process iteratively to get some
> idea of the ultimate number of recipients.
ames!nyu.edu!phri!roy (Roy Smith) writes:
> And then, don't forget to add in all the people who read TCP-IP as
> its usenet alter ego, comp.protocols.tc-ip.
Also don't forget the bitnet shadow list TCPIP-L at BYUADMIN!
Ted Schroeder ultra!ted@Ames.arc.nasa.GOV
Ultra Network Technologies
2140 Bering drive with a domain server:
San Jose, CA 95131 ted@Ultra.COM
408-922-0100
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 21:34:22 GMT From: kwang@bud.UUCP (Kwang Sung) To: comp.protocols.tcp-ip Subject: Re: Van Jacobson's Algorithm for AT&T Stream Implementations
I hope someone on the net can answer to my question. I am curious that whether we can apply Van Jacobson's Algorithm to AT&T Stream TCP/IP implementations easily. I would like to know more detail about Van Jacobson's Algorithm clearly.
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 3 Aug 88 22:13:09 GMT From: kwang@bud.UUCP (Kwang Sung) To: comp.protocols.tcp-ip Subject: Re: Difference between 4.3 BSD and 4.4 BSD, and between V.3 and V.4
I hope someone can answer to my question. I would like to know difference between 4.3 BSD and 4.4 BSD, and between AT&T V.3 and AT&T V.4, in terms of networking implementations.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 00:02:30 GMT From: chris@GYRE.UMD.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: Re: HP TCP/IP Conformance
From: Walter Underwood <wunder@sde.hp.com> I think this is worth answering to the whole list. HP's Unix machines do implement a full TCP/IP, and do work with other systems. The networking is based on 4.2 BSD, and will be upgraded to use the Van Jacobson algorithms at the earliest possible time. ... I am not sure that anything based on 4.2BSD is `full TCP/IP' (unless it has had all the 4.3BSD fixes added), but in any case, 4.3BSD is available for the HP9000 Series 300, from the University of Utah. Chris
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 00:14:22 GMT From: amdahl!bungia!datapg!questar!bthpyd!wiebe@ames.arc.nasa.gov (Glen Wiebe) To: tcp-ip@sri-nic.arpa Subject: Micom-Interlan NP100 ethernet woes
We are in the process of installing a couple of Micom-Interlan NP100 ethernet boards in two VAX 750s. One I can get working and the other I cannot. The VAX 750 on which it works has disks connected to an Emulex massbus disk controller. The VAX 750 on which I have trouble has one RA81 disk on a DEC UDA50 disk controller. (I suspect this may be the problem). We are running the original 4.3bsd release. When powering up the system the NP100 goes through a series of internal self diagnostics. It never completes these successfully and the driver (ix0) for the NP100 cannot reset it (it times out waiting for a response). The NP100 board is ok since it works fine in the other VAX. Does anyone have ideas on what the problem might be? Thanks. -------- Glen J. Wiebe UUCP rutgers!bungia!bthpyd!wiebe Bethel College, St. Paul, MN ATT (612) 638-6106
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 00:52:00 GMT From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Re: subnet IP mask stored in route or interface struct?
Dennis Bednar (decwrl!sun!pitstop!sundc!rlgvax!dennis) asks:
Does 4.3BSD store the IP subnet mask in the route structure
(struct rtentry) or the interface structure (struct ifnet)?
The reason I ask, is that RFC 950 suggests that it be stored
on a per interface basis. However, I have found a particular
case (described below), in which it is better to store the mask
on a per route basis. Perhaps the example I have contrived
violates an unmentioned assumption that subnets in the same
network should be adjacent.
Yes, but this is not so much an "unmentioned assumption" as it is
a rule that is not stated in the most obvious place. As an author
of RFC950, I suppose I must take the blame for not repeating in
RFC950 this statement from the first page of RFC940:
The use of subnets is an optional local decision. The fact that a
network has subnets is invisible outside that network, and the change
is local and can be instituted at a site without any global Internet
perturbations. A complex of links is assigned a single IP network
number, and outside that complex it appears as a single network with
that number. Only inside does local structure appear.
[Note that the first paragraph of RFC950 says, in effect, "read RFC940."]
Following this rule, the "particular case" is in violation:
--------------------gw1----------------gw2------------------
Name subnet1 network subnet2
Number 192.7.8.0x10 128.5.0x10 192.7.8.0x20
because the distinction between subnet1 and subnet2 would have to be
visible outside network 192.7.8.0 in order for things to work.
Solutions: Use different Class C numbers for the two isolated pieces,
or tie them together with a gateway connected to both subnets. The latter
solution is less likely to fill up other people's routing tables.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 02:29:56 GMT From: wunder@SDE.HP.COM (Walter Underwood) To: comp.protocols.tcp-ip Subject: HP TCP/IP Conformance
I am not sure that anything based on 4.2BSD is `full TCP/IP' (unless it has had all the 4.3BSD fixes added), ... I agree, and the people that work on our TCP agree. We have fixed the behavior, but it is still a 4.2 programming interface. That is why I pointed out the 4.2 heritage. Geez, I'd almost forgotten how bad 4.2 was ... wunder
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 1988 06:50-EDT From: CERF@A.ISI.EDU To: rochester!srs!dan@BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP/IP and NFS for MacOS?
I have been given to understand that there is a Unix for the MAC. If that is true, NFS should be available as well. The MAC Unix is called AUX, I believe. I don't have a point of contact, but the product is supported by Apple, I believe. Vint Cerf
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 03:09:56 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Status of NTP?
Deke, See RFC-1059. Then, you might want to talk to Mike Petry, who has a 4.3bsd daemon which is now chiming at a few dozen systems just now. Also, a bunch of new radio clocks have come up, making the total at least seven going on nine. Depending on your confidence and precision required, you might want to run NTP on only a few of your machines and timed on the rest; however, NTP depends for robustness on having a number of peers and using a weighted selection algorithm to cast out the falsetickers. Dave
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 1988 07:19-EDT From: CERF@A.ISI.EDU To: rochester!ur-tut!ur-valhalla!deke@CU-ARPA.CS.CORNELL.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Status of NTP?
Deke, NTP RFC 1059 dated July 88 just released. RFC 1059 is an elective protocol and the RFC is in DRAFT STANDARD status. Vint Cerf
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Aug 88 12:02 EST From: <JFISHER%USGSRESV.BITNET@CUNYVM.CUNY.EDU> (James R. Fisher) To: tcp-ip@sri-nic.arpa Subject: tcp/ip for Amdahl UTS
Hello: We will soon be running Amdahl's UTS (Unix) version 1.2 under VM/HPO on an Amdahl 5890. We want a tcp/ip implementation for it; I'd be happy to hear from anyone out there who knows any vendors of tcp/ip for such an environment. Thanks much. Jim Fisher jfisher@usgsresv.bitnet
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 10:50:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: TCP/IP and NFS for MacOS?
I have been given to understand that there is a Unix for the MAC. If that is true, NFS should be available as well. The MAC Unix is called AUX, I believe. I don't have a point of contact, but the product is supported by Apple, I believe. Vint Cerf
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 11:19:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Status of NTP?
Deke, NTP RFC 1059 dated July 88 just released. RFC 1059 is an elective protocol and the RFC is in DRAFT STANDARD status. Vint Cerf
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 13:11:48 GMT From: stjohns@BEAST.DDN.MIL (Mike St. Johns) To: comp.protocols.tcp-ip Subject: TCP/IP and NFS for MacOS?
This month's BYTE has a rather scathing set of articles on A/UX - Unix for the MAC. A/UX appears to be closest to system V than any of the other UNIXs. But hold on to your wallet - it costs either $5000 or $10,000 depending on your system configuration - this is *without* source code (which does not appear to be available at this time) Mike
-----------[000042][next][prev][last][first]----------------------------------------------------
Date: 4 Aug 88 13:25:00 GMT
From: LENTZ@NUACC.ACNS.NWU.EDU ("Beat the system, pull the plug.")
To: comp.protocols.tcp-ip
Subject: TCP-IP for AT&T UNIX-PC 7300'sSubject: TCP-IP for AT&T UNIX_PC 7300's I hope someone can help me. I am a student in the Integrated Science Program at Northwestern University and we would like to hook our 7300's to the local campus network. This requires TCP/IP software, which we do not know where to obtain. Can anyone make any recommendations? Also can the 7300 handle a 19200bps line for the connection? I seem to remem- ber some discussion regarding this problem a couple of weeks ago but skipped over it at that point as it was not relevent then. Will modifications to the daemons help reduce the overhead so that the 7300 will be able to keep up with the traffic it must handle? Please excuse any ignorance on my part as I am still new to UNIX and the 7300's. Thanks. Robert Lentz Bitnet: Lentz@Nuacc Internet: Lentz@Nuacc.Acns.Nwu.Edu P.S. If anybody can recommend a good source for MMDF or another good mail program this would also be appreciated.
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 13:52:09 GMT From: ooblick@lts.UUCP (Mikki Barry) To: comp.newprod,comp.protocols.tcp-ip,comp.sys.mac Subject: TCP/Connect - NCSA Telnet Plus Support
Learning Tree Software, Inc. would like to announce the formation of a new company: InterNet Systems Corporation. ISC is modifying the existing NCSA Telnet for the Macintosh to produce new and nifty features, and is offering telephone support. We will begin shipping this new product Sept. 1. The price of $495 (with substantial discounts for multiple copies) includes an updated manual, the software, and one year of telephone support. Current NCSA Telnet users can contact us for special pricing. (703) 435-8170. Until InterNet Systems Corp. gets on the net, LTS will forward mail sent to uunet!lts!comment. InterNet Systems Corp. will be at MacWorld sharing the Kinetics booth. We will have a special show discount for this product, as well as RealTalk, a new and nifty product similar to "talk" on Unix systems. It also includes a file transfer program, and window servers. Current pricing is $79.95 for one, or $219.95 for a three pak (in a peachy keen binder that will light up your bookshelf). It has so many neato features that you really should come see it at MacWorld. Mikki Barry Grand Poohbah
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 14:02:16 GMT From: jqj@HOGG.CC.UOREGON.EDU To: comp.protocols.tcp-ip Subject: Ken Olsen on TCP/IP
Quoted without permission from Digital News, August 1, 1988: "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big system, because we can't fix it if it breaks.'" Does this reflect a lack of confidence in the Ultrix group?
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 14:18:57 GMT From: jas@proteon.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: subnet IP mask stored in route or interface struct?
Your configuration is illegal per RFC 1009. To quote:
The interconnected LANs of an organization will be given the
same network number but different subnet numbers. The
distinction between the subnets of such a subnetted network
must not be visible outside that network. Thus, wide-area
routing in the rest of the Internet will be based only upon the
<Network-number> part of the IP destination address; gateways
outside the network will lump <Subnet-number> and <Host-number>
together to form an uninterpreted "rest" part of the 32-bit IP
address.
The whole point of subnets is to provide a LAYERED, HEIRARCHICAL
approach to routing. Anyone outside the subnetted network must be
able to route solely on the basis of network number. Hosts on your
network 128.5 cannot do this. Your configuration does not work
because it is illegal.
It is surely possible to envision all sorts of ways of "solving" this
supposed problem. But then you will fail to solve the problem that
subnetting was intended to solve. That problem was that routing at
the upper (network) layer was overloading from too many networks.
Subnets, by hiding a layer of the network topology, solved this. The
restrctions of subnets are readily dealt with by proper (sub)network
design.
[The same approach was applied to DECnet in Phase IV, with areas.
What you are asking for is the equivalent of allowing node 7.33 in
DECnet to plopped down in the middle of area 5 and have it work.]
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 14:40:03 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: Precedence & IP Options (was: HP TCP/IP Conformance)
I can testify that HP UX doesn't have the 4.2 "crash on unknown IP option" bug (which at least a couple of other 4.2-derived Unices still have). If you (or anyone else) have Internet hosts which you would like to check out with TCP using Precedence and the IP Basic & Extended Security options, send me mail, giving the name & IP address, and any other constraints you would like to impose (I will not be able to deliver on 'a phone call before you try it'). Commercial IP routers from Proteon, and the MIT C-gateway, are known to forward packets containing these options. 4.3 Unix and cisco terminal concentrators handle them correctly at the application layer, so I have hopes that 4.3 & cisco routers will forward them as well. If you are connected to the Internet via a 4.2-based router, it may fail to forward the packets, or even crash. I will reply with e-mail declaring a time when I will do the testing (which can interrupt operations on some hosts, e.g. SunOS 3.4 and Ultrix 2.0). I will use ICMP Echo Request and TCP (usually finger, Telnet or SMTP if finger isn't supported) to test behaviour. Symptoms I have observed while testing the Basic & Extended security options include: Go deaf to the net for 5 minutes on either Ping or TCP (but not crash) Ignore Ping, crash on TCP or UDP. Ignore Ping and TCP. Ignore Ping, Reset attempted TCP connections. Ignore Ping, open TCP connections ok. Reply w/o option to Ping, open TCP connections ok. Reply w/option to Ping, ignore TCP connection attempts. Reply w/option to Ping, Reset attempted TCP connections. Reply w/option to Ping, open TCP connections ok. The current list of implementations that I have observed correctly supporting TCP with IP Precedence is: Wiscnet on IBM VM systems. KA9Q on IBM PCs. PC/TCP v2.03 (in beta test). The list of implementations which I have observed as unable to handle the RFC-1038 IP Security options will appear later this month. James VanBokkelen FTP Software Inc. (617) 868-4878 jbvb@vax.ftp.com
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 15:52:28 GMT From: don@SRI-LEWIS.ARPA (Donald Holman) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and NFS for MacOS?
> Mike St. Johns writes: > > But hold on to your wallet - it costs either $5000 or $10,000 > depending on your system configuration - this is *without* source code > (which does not appear to be available at this time) If this is indeed the cost, it might be less expensive to get source code from another place, and then pay a team of developers to adapt it for the new machine. Not necessarily a joke, but perhaps a semi scathing commentary on the price. these are my comments and are probably not the views of my employer. Don
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 16:49:56 GMT From: tjb@Apple.COM (Tom Barrett) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and NFS for MacOS?
In article <8808041311.AA03609@beast.DDN.MIL> stjohns@BEAST.DDN.MIL (Mike St. Johns) writes: >This month's BYTE has a rather scathing set of articles on A/UX Scathing...hmmm...in my humble interpretation, I would say perhaps lukewarm. The summary in the review says "...[A/UX is] a good first step toward the MacII into a Unix workstation." Anyway, lest I be accused of out-of-context quoting, it's best to judge for one's self. A recent issue of UNIX World had a fairly positive review (not sure which issue, sorry), as did the June 27 issue of UNIX Today (BTW, I am a contractor, not an Apple employee). >But hold on to your wallet - it costs either $5000 or $10,000 >depending on your system configuration - this is *without* source code I'm not sure if it's clear from this posting that these prices include the fully configured MacII (monitor, floppies, 80Mb hard drive, etc.). Those interested in details about A/UX can read or post requests to comp.unix.aux.
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 17:02:00 GMT From: JFISHER@USGSRESV.BITNET (James R. Fisher) To: comp.protocols.tcp-ip Subject: tcp/ip for Amdahl UTS
Hello: We will soon be running Amdahl's UTS (Unix) version 1.2 under VM/HPO on an Amdahl 5890. We want a tcp/ip implementation for it; I'd be happy to hear from anyone out there who knows any vendors of tcp/ip for such an environment. Thanks much. Jim Fisher jfisher@usgsresv.bitnet
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 17:17:27 GMT From: adelman@WARBUCKS.AI.SRI.COM (Kenneth Adelman) To: comp.protocols.tcp-ip Subject: Re: Question about TCP/IP on VMS
> I currently have an application running on Ultrix which uses TCP/IP.
> Each machine in the network has a server running on it. The server is
> opened in passive mode and listens at a known port for traffic. Under
> Ultrix this "known port" is defined by adding an entry for my server
> into the file /etc/services. How is this done under VMS? How are the
> well-known ports defined? Or does this depend on the TCP/IP software
> you have?
Depends on the TCP/IP software you have. On MultiNet you add an
entry to a text file which gets compiled into a binary database and
loaded into a global section for fast access. On WINS/TCP I believe
that you add an entry to the etc:[000000]services file just like under
Unix. Well known ports don't HAVE to be defined in these files, it
just makes it convenient because your code can reference the port by
name instead of number.
Kenneth Adelman
TGV
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 20:08:55 GMT From: timk@NCSA.UIUC.EDU (Tim Krauskopf) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and NFS for MacOS
The misinformation is getting a little thick. AUX for Apple's Macintosh II is a port of System V with BSD networking, (I don't know how many 4.3 enhancements are in 1.0, 1.1 should be full 4.3BSD TCP/IP) other BSD enhancements and full NFS support. It works. Right now it is plain vanilla, X is coming, black and white only for now, Mac ToolBox graphics are available. The auto-config has everyone else's UNIX beat. Running AUX doesn't prevent you from running MacOS, just takes up a whole 80MB drive. AUX does NOT cost more than $1000. If you buy two Mac II systems with identical hardware, one with AUX and the other with MacOS (the original Macintosh operating system), then you will find the cost of AUX is anywhere from $200 to $500 depending on the hardware you actually buy. Plus manuals, 6-foot set, isn't real cheap, order separately. If you call the extra expense of the hard disk a part of the UNIX cost, then you haven't been running many Suns. This is a full product line, dealers and everything, contact your nearest AUX-certified Apple dealer or a sales office. Below this line, I am referring to MacOS, NOT AUX. For you PC users, think of this as DOS vs. XENIX, one has the applications, the other is UNIX. ------------------------ There is no commercial NFS for the Mac. Cayman Systems (Cambridge, MA, (617)494-1999) is releasing "real soon now" a box which converts NFS to AFP, the Apple Filing Protocol standard for shared disks under MacOS. NFS for MacOS in software is doable, primarily for Ethernet-equipped Macs, no announcements that I know of. TCP/IP for MacOS has been announced as "in development" at Apple in Cupertino. Target for release is before end of 1988. Demos scheduled for the TCP/IP Interoperability Conference in September. There are no commercial releases of TCP/IP or TCP/IP applications for MacOS shipping that I know of at the time I am writing this. Before the end of the year, expect 4 or more vendors to ship. University products are available from Cornell, Brown, Illinois (NCSA), Michigan, and Stanford, but some are restricted use. I am biased, Anonymous FTP to 128.174.20.50 for release package and source to NCSA Telnet for the Macintosh. What can you lose, it's public domain? I tried to stick to facts, but if there are any opinions above, they are my own. Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) National Center for Supercomputing Applications (NCSA) University of Illinois, Urbana-Champaign
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 88 20:17:27 GMT From: john@twg-ap.UUCP (John Caughy) To: comp.protocols.tcp-ip,comp.os.vms Subject: Re: TCP/IP on VMS 5.0
From article <12515@ism780c.isc.com>, by bobn@ism780c.isc.com (Robert Noh): > > On a related note, does anyone have a list of TCP/IP implementations > that run on a multiprocessor machine? This is more for a reference > than anything else, but I still would like the information. > The implementation for the HP 9000 500 series from Wollongong operates in a multiprocessor environment. The TCP/IP provides a single thread for all users of the system and appears to be quite responsive.
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 08:16:00 PDT From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: RE: Van's algorithm's in Streams
This is in response to Kwang Sung's query: Our newest version of Streams TCP contains Van's and Nagles algorithms for congestion control, etc. The header-predection performance code is scheduled for addition, shortly, although we are still trying to understand its impact under mixed traffic conditions. Dave Crocker VP, Engineering The Wollongong Group
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 09:37:00 PDT From: Leo J McLaughlin <ljm@twg.com> To: tcp-ip <tcp-ip@louie.udel.edu> Subject: 802.3 routing
>> A few weeks ago, i saw something mentioned concerning problems with >> HP systems with TCP/IP. ... >> We are currently looking at various vendors for networkable >> workstations, an HP is one of the contenders, if you or they can >> show us that their workstations support TCP/IP and/or Ethernet >> networking with minimal 'adjustments'. >The HP3000 uses proprietary login and file transfer protocols. >Regular ARPA services (Telnet, FTP, and SMTP) are available from The >Wollongong Group. >If you have MPE systems, you need a gateway that talks 802.3 and >Probe. The only gateways that do that are the HP9000 series 300 and >series 800 machines (HP-UX), and boxes from cisco Systems, Inc. >Walter Underwood >HP Software Engineering Systems >Palo Alto, CA The Wollongong Group also provides a product that allows a PC to function as a gateway for MPE systems, WIN/ROUTE2. leo j mclaughlin iii Project Leader The Wollongong Group
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 06:09:43 GMT From: chris@GYRE.UMD.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: Re: Difference between 4.3 BSD and 4.4 BSD, and between V.3 and V.4
4.4BSD does not exist. There is a post-4.3-BSD release of TCP; it is available via anonymous FTP from Berkeley.edu. It implements the `Jacobsen/Karels' algorithms. (The new TCP code is included in 4.3BSD-tahoe.) Chris
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 08:28:00 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip, root@sbcs.sunysb.edu Subject: Re: BOOTP vendor support
The only vendor that I know uses bootp is cisco. Their gateways can use it to get IP addresses. (They can also use RARP - they send both types of request, and believe whichever response they hear.) They also have the code needed to pass bootp requests across gateways. I've never understood why other vendors don't use it, since it's clearly easier to install than RARP, and more general. I've not had any trouble bringing up bootp on Unix systems, and it should also be possible on Unix-based stuff like TWG's IP for VMS. I'd be inclined to use bootp anyway for any new products.
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 1988 13:43-EDT From: CERF@A.ISI.EDU To: LENTZ@NUACC.ACNS.NWU.EDU Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: TCP-IP for AT&T UNIX-PC 7300's
FTP Software can supply PC-based TCP/IP if you are running MS/DOS. FTP Software is in Cambridge, MA. There are undoubtedly other sources of supply including freeware say from MIT/LCS. The DDN Network Information center at SRI International is another good place to check - they have a lengthy catalog of software which they have compiled as "DDN Protocol Implementations and Vendors Guide" NIC 50002. It is also available on-line at SRI-NIC.ARPA. MMDF is available from Prof. David Farber, University of Pennsylvania, Computer and Information Systems: farber@cis.upenn.edu Vint Cerf
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 16:51:00 PDT From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: Re: Accidentally including the CC line
This is in reply to Bob <enger@gburg.scc.com> note: Some people may have missed the trailing smile at the end of your comment about wishing you could accidentally replying to CC recipients. I force myself to use our VMS product, mostly out of masochism but partly so issues such as the one you raise are familiar. Keith McCloghrie works on a number of our products, but not the VMS one, so he can affort the luxury of using a Unix interface (MH, when last I checked). Why should I burden everyone with this clarification? Well, the problem is that the VMS user interface to mail, with our TCP product, is standard DEC issue, called VAXmail. While we have integrated into it as best possible, through their foreign service interface, we do not touch the basic vaxmail product. We are thinking of offering a richer mail system for a number of platforms, but that is mostly my way of trying to find an excuse to use some old but fondly rememebered experiences. Another alternative, shortly, will be All-In-One. Dave Crocker The Wollongong Group
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 10:36:55 GMT From: chris@GYRE.UMD.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: Re: Micom-Interlan NP100 ethernet woes
The NP100 driver included in 4.3BSD (presumably written by or for Interlan; at any rate, it was not done at Berkeley) is egregiously buggy. A later revision of the driver (done after Berkeley got an NP100) is available from Berkeley, either as part of 4.3BSD-tahoe or separately. Contact Keith Bostic <bostic@okeeffe.berkeley.edu> if you need just the driver. Chris
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Aug 88 17:01 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)", <LEICHTER@Venus.YCC.Yale.Edu> To: tcp-ip@sri-nic.arpa Subject: Moderated Newsgroup Posting
Path: venus!leichter From: leichter@venus.ycc.yale.edu Newsgroups: mail.tcp-ip Subject: Re: Ken Olsen on TCP/IP Message-ID: <34@venus.ycc.yale.edu> Date: 5 Aug 88 17:01:31 GMT References: <venus mail.tcp-ip:1807> Organisation: VMS NEWS V4.0 Lines: 32 In article <venus mail.tcp-ip:1807>, jqj@hogg.cc.uoregon.EDU writes: > Quoted without permission from Digital News, August 1, 1988: > > "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big > system, because we can't fix it if it breaks.'" > > Does this reflect a lack of confidence in the Ultrix group? The actual, full quote - from Ken Olsen - is: "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big system, because we can't fix it if it breaks - nobody can.'" ------------- It's generally considered unfair to quote out of context. To CHANGE the con- text - to deliberately mark something as a full sentence, with no indication that you've left out part of the text, a part which changes the mean of what came before - is bad enough. To then continue on and ask a question based on the falsely-imputed meaning is downright dishonest. Olsen goes on to clarify what he means even further: "TCP/IP is OK if you've got a little informal club, and it doesn't make any difference if it takes a while to fix it." Now, you can disagree with this statement - probably most of the readers of this list WILL disagree, though perhaps not all. But there's a world of difference between disagreeing on the merits, and the intellectual dishonesty of picking words OUT OF THE MIDDLE OF A SENTENCE and ascribing a new meaning to them that wasn't there to start with. -- Jerry
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 13:35:04 GMT From: stjohns@BEAST.DDN.MIL (Mike St. Johns) To: comp.protocols.tcp-ip Subject: TCP/IP and NFS for MacOS?
There were actually two articles - one about Apple in general, and another about the A/UX stuff. The one about Apple in general starts out with "... A/UX is another of Apple's software mistakes." The other article was kinder. Mike (THis is the August 1988 issue of Byte we are discussing /msj/)
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 14:08:09 GMT From: alan@cunixc.columbia.edu (Alan Crosswell) To: comp.protocols.tcp-ip Subject: Re: BOOTP vendor support
Cisco's bootp also works on the terminal server in SLIP mode. I've used the CMU PCIP distribution with it and it worked first time. No more custom netdev on 8 million PC's. /a
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 14:13:30 GMT From: dnwcv@dcatla.UUCP (William C. VerSteeg) To: comp.protocols.tcp-ip Subject: Re: BOOTP vendor support
I agree with the opinion that BOOTP is a good way to initialize a dumb device. We at Digital Communication Associates are designing new products that use BOOTP and TFTP to downline load code and configurations. A manufacturer of communications equipment has a great deal of impetous to support these protocols. He requires them to boot. We will support BOOTP on both our large, disk based systems and our small diskless units. In a typical configuration, the dumb devices will boot from the disk-based units. When a customer wants only the smaller, cheaper units, they will have to boot from another vendor's device. I am curious whether the minicomputer-oriented vendors will include support for BOOTP in their standard distributions. TWG, SRI, NRC, etc would be well served by including as much functionality as possible. However, I wonder if the minicomputer manufacturers will be as likely to support a protocol to load generic hardware. Would they fear selling fewer units of there own diskless stations and terminal servers ? I also would like to know of other BOOTP implementations to test against. Bill VerSteeg DCA
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 15:16:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: RE: Van's algorithm's in Streams
This is in response to Kwang Sung's query: Our newest version of Streams TCP contains Van's and Nagles algorithms for congestion control, etc. The header-predection performance code is scheduled for addition, shortly, although we are still trying to understand its impact under mixed traffic conditions. Dave Crocker VP, Engineering The Wollongong Group
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 16:18:01 GMT From: spl1!laidbak!stevea@elroy.jpl.nasa.gov (Steve Alexander) To: tcp-ip@sri-nic.arpa Subject: Re: Van Jacobson's Algorithm for AT&T Stream Implementations
In article <160@bud.UUCP> kwang@bud.UUCP (Kwang Sung) writes:
>I am curious that whether we can apply Van Jacobson's Algorithm to
>AT&T Stream TCP/IP implementations easily.
Lachman's System V STREAMS TCP has been shipping with Van's TCP (as
well as the latest UCB IP and UDP fixes) since June. Van's algorithms
were easy to integrate into our code. The fact that we run over STREAMS
had no impact at all.
At the performance seminar in May, a great deal of material was handed
out that described these enhancements. Perhaps ACE has extra copies
that you could obtain from them.
Their address is:
Advanced Computing Environments
480 San Antonio Rd, Suite 100
Mountain View, CA 94040
415-941-3399
Hope this helps...
Steve Alexander, TCP/IP Development | stevea%laidbak@sun.com
Lachman Associates, Inc. | ...!{ihnp4,sun}!laidbak!stevea
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 16:37:56 GMT From: dab@ALLSPICE.LCS.MIT.EDU To: comp.protocols.tcp-ip Subject: Re: BOOTP vendor support
Not exactly a vendor, but the MIT uVAX C-Gateway also uses bootp, not only to find out its IP address but also to invoke TFTP to boot the gateway code. The gateway code also has the ability to forward bootp requests through to appropriate bootp servers if necessary. With the one exception that the boot code had to be specific to a subnet (because the 4.2 servers would only recognize broadcast addreses of the form net.subnet.0) bootp has worked very well. Also, CMU has been using bootp to auto-configure IBM PC's for quite a while using the bootp vendor field to set the various other things the PC's need to know. [Now for the vendor support part] We'll be including a bootp client for configuring PC's using the CMU style vendor field (actually either CMU style or RFC-1048) with our next release. David Bridgham FTP Software
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 17:15:36 GMT From: cam%columbia-pdn@ACC-SB-UNIX.ARPA (Chris Markle acc_gnsc) To: comp.protocols.tcp-ip Subject: Enet + TCP/IP for Honeywell
Folks, Does anyone know of a tcp/ip implementation for Honeywell systems and the associated enet hardware? Chris Markle - ACC cam%columbia-pdn@acc-sb-unix.arpa
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 17:43:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: TCP-IP for AT&T UNIX-PC 7300's
FTP Software can supply PC-based TCP/IP if you are running MS/DOS. FTP Software is in Cambridge, MA. There are undoubtedly other sources of supply including freeware say from MIT/LCS. The DDN Network Information center at SRI International is another good place to check - they have a lengthy catalog of software which they have compiled as "DDN Protocol Implementations and Vendors Guide" NIC 50002. It is also available on-line at SRI-NIC.ARPA. MMDF is available from Prof. David Farber, University of Pennsylvania, Computer and Information Systems: farber@cis.upenn.edu Vint Cerf
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 18:55:34 GMT From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) To: comp.protocols.tcp-ip Subject: Re: Micom-Interlan NP100 ethernet woes
Substantial changes have been made to the Interlan np100 driver that was distributed with 4.3BSD. If anyone is attempting to use this driver, please contact me for a new copy. Keith Bostic bostic@ucbvax.berkeley.edu uunet!keith
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 18:59:00 GMT From: dan@srs.UUCP (Dan Kegel) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Summary: TCP/IP and NFS for the Mac
I recently asked the net for info about networking for the Mac SE, and
recieved many helpful responses.
There seem to be only two systems that let plain old Mac programs transparantly
access files on a remote Unix fileserver:
1. TOPS, a proprietary network file system developed independantly
and later purchased by Sun; this has been available for some time.
The only Unix box that TOPS currently runs on is the Sun-3.
Either LocalTalk or Ethernet may be used to connect the Macs to the Sun.
TOPS phone number is (800) 445-8677 or (415) 769-8700.
System cost:
Software:
TOPS server on Sun ($900 for 1-4 clients, $1600 for 1-16 clients)
TOPS client on Mac ($250 per client)
Hardware:
using LocalTalk: $50 per client + $2000 for the Kinetics Fastpath bridge
using EtherTalk: $600 per client
2. Cayman Systems' Gatorbox, an NFS (Ethernet) to AFP (LocalTalk) bridge;
the box and software sell for $3495, and takes about 6 weeks to get.
The Unix box must be running NFS (and most can; many are shipped with it).
It links up to 32 Macs running Apple's network (AFP on LocalTalk) to
a standard Ethernet network.
Cayman Systems' phone number is (617) 494-1999.
System cost:
$50 per client (for LocalTalk cable) + $3500 for the Gatorbox bridge
Other NFS systems, rumored but not currently available, are
3. University of Michgan had a client version of NFS for the Mac at last
years Sun Connectathon. Don't think they ever fielded it.
4. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project
that put tcp/ip and NFS on Macs, under contract to Apple.
Apple has the software now; it's unclear when if ever they will release it.
LocalTalk is Apple's 200 kilobit/sec serial networking hardware, which
is quite slow compared with the 10 Megabit/sec Ethernet;
one might therefore expect to be able to connect up only five or ten Macs
per LocalTalk bus before seeing degradation, as opposed to fifty or so on an
Ethernet bus. (I've never tried it, so I dunno.)
There are also systems available that let TCP/IP aware programs communicate
with other machines on an Ethernet; this isn't as nice as transparant file
access, but it can be pretty darn useful.
1. Kinetics sells Ethernet boards for all versions of the Macintosh; it
also sells a TCP/IP (Ethernet) to TCP/IP (Appletalk) bridge.
2. NCSA maintains a professional-looking TELNET package for the PC and the Mac
which supports remote login, multiple VT102 emulation, Tek 4014 emulation,
subnetting, and dynamic IP address assignment via RARP.
I think this is shipped with Kinetics equipment.
It is available for anonymous FTP over the Darpanet from
ftp.ncsa.uiuc.edu (128.174.20.50). Contacts listed on their blurb:
Tim Krauskopf timk@ncsa.uiuc.edu (ARPA)
Gaige B. Paulsen gaige@ncsa.uiuc.edu
National Center for Supercomputing Applications (NCSA)
University of Illinois, Urbana-Champaign
3. Either Stanford or Columbia maintain something called KIP and CAP
which seems to be another TCP/IP package; NCSA would know more about it.
4. Phil Karn's KA9Q package is another (public-domain?) TCP/IP implementation.
Thanks to everybody who replied. I'm still looking for something that
supports NFS over Ethernet right to the Mac...
--
Dan Kegel "We had to get it passed before the columnists attacked!"
srs!dan@cs.rochester.edu rochester!srs!dan dan%srs.uucp@harvard.harvard.edu
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 20:29:51 GMT From: ozalp@aya.cs.cornell.edu (Ozalp Babaoglu) To: comp.protocols.tcp-ip Subject: x.25 as an internet backbone
suppose a country (italy, to be precise) currently has a single internet site (in pisa) and has been registered as a top-level domain (domain .IT). there are three class C type IP addresses allocated to the country. what are some reasonable ways to structure subdomains in this country domain and incorporate LANs at other sites (cities) into the internet? the physical transport medium available is x.25 (both private and PDN run by the telephone company). what is the technology of choice for ethernet-x.25 gateway hardware and the software to do the routing and encapsulation (of IP packets over x.25)? any suggestions will be appreciated. ozalp babaoglu
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 02:53:00 EST From: "BARRY NEWTON" <newton@enh.nbs.gov> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Advertising
If everybody on the tcp-ip distribution list were to give the "Grand Poohbah" one telephone call on his thoughtfully provided number, he might come to a more clear understanding of the value and consideration involved in keeping crowded resources clear... But don't do it. It wouldn't be nice:-) Barry
-----------[000073][next][prev][last][first]----------------------------------------------------
Date: 5 Aug 88 22:01:00 GMT
From: LEICHTER@Venus.YCC.Yale.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
To: comp.protocols.tcp-ip
Subject: Moderated Newsgroup PostingPath: venus!leichter From: leichter@venus.ycc.yale.edu Newsgroups: mail.tcp-ip Subject: Re: Ken Olsen on TCP/IP Message-ID: <34@venus.ycc.yale.edu> Date: 5 Aug 88 17:01:31 GMT References: <venus mail.tcp-ip:1807> Organisation: VMS NEWS V4.0 Lines: 32 In article <venus mail.tcp-ip:1807>, jqj@hogg.cc.uoregon.EDU writes: > Quoted without permission from Digital News, August 1, 1988: > > "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big > system, because we can't fix it if it breaks.'" > > Does this reflect a lack of confidence in the Ultrix group? The actual, full quote - from Ken Olsen - is: "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big system, because we can't fix it if it breaks - nobody can.'" ------------- It's generally considered unfair to quote out of context. To CHANGE the con- text - to deliberately mark something as a full sentence, with no indication that you've left out part of the text, a part which changes the mean of what came before - is bad enough. To then continue on and ask a question based on the falsely-imputed meaning is downright dishonest. Olsen goes on to clarify what he means even further: "TCP/IP is OK if you've got a little informal club, and it doesn't make any difference if it takes a while to fix it." Now, you can disagree with this statement - probably most of the readers of this list WILL disagree, though perhaps not all. But there's a world of difference between disagreeing on the merits, and the intellectual dishonesty of picking words OUT OF THE MIDDLE OF A SENTENCE and ascribing a new meaning to them that wasn't there to start with. -- Jerry
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 23:23:37 GMT From: winter@Apple.COM (Patty Winter) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Summary: TCP/IP and NFS for the Mac
In article <944@srs.UUCP> srs!dan@cs.rochester.edu (Dan Kegel) writes:
>
>4. Phil Karn's KA9Q package is another (public-domain?) TCP/IP implementation.
^^^^^^^^^^^^^^^^
For amateur radio and university research uses, yes. Otherwise, no.
Patty
=============================================================================
Patty Winter N6BIS DOMAIN: winter@apple.com
AMPR.ORG: [44.4.0.44] UUCP: {decwrl,nsc,sun}!apple!winter
=============================================================================
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 88 23:51:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: Re: Accidentally including the CC line
This is in reply to Bob <enger@gburg.scc.com> note: Some people may have missed the trailing smile at the end of your comment about wishing you could accidentally replying to CC recipients. I force myself to use our VMS product, mostly out of masochism but partly so issues such as the one you raise are familiar. Keith McCloghrie works on a number of our products, but not the VMS one, so he can affort the luxury of using a Unix interface (MH, when last I checked). Why should I burden everyone with this clarification? Well, the problem is that the VMS user interface to mail, with our TCP product, is standard DEC issue, called VAXmail. While we have integrated into it as best possible, through their foreign service interface, we do not touch the basic vaxmail product. We are thinking of offering a richer mail system for a number of platforms, but that is mostly my way of trying to find an excuse to use some old but fondly rememebered experiences. Another alternative, shortly, will be All-In-One. Dave Crocker The Wollongong Group
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 01:20:32 GMT From: root@sbcs.sunysb.edu (root) To: comp.sys.mac,comp.protocols.tcp-ip Subject: Re: Summary: TCP/IP and NFS for the Mac
This is a bit tangential an answer to the original question "Who has NFS on MacOS?". For small machines there are NFS implementations available for both the IBM PC and Amiga. Sun sells PC-NFS for the IBM PC - package price is ~$900. Ameristar Technology sells NFS for the Amiga - package cost also $900. Since part of my time is spent at Ameristar, I'll allow myself the luxury of giving their phone number: (516) 698-0834. You probably already know how to contact Sun anyways :-). Rick Spanbauer Ameristar Technology PS. I would like to hear from anyone who has a Gator Box.
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 01:48:29 GMT From: davidc@TERMINUS.UMD.EDU (David R. Conrad) To: comp.protocols.tcp-ip Subject: Re: BOOTP vendor support
Add the University of Maryland to the list of Universities that use bootp for PCs. Our public workstation labs use it with RFC1048 extensions to provide information for the TCP/IP for the PC that we use here. We currently use a bootp server per subnet so we don't have to worry about gateways forwarding requests although our bootp server (based on CMU's with local additions) does have forwarding capabilities. We'd also be interested in having more vendors (particularly Proteon) support bootp forwarding -drc
-----------[000078][next][prev][last][first]----------------------------------------------------
Date: 6 Aug 88 07:53:00 GMT
From: newton@ENH.NBS.GOV ("BARRY NEWTON")
To: comp.protocols.tcp-ip
Subject: AdvertisingIf everybody on the tcp-ip distribution list were to give the "Grand Poohbah" one telephone call on his thoughtfully provided number, he might come to a more clear understanding of the value and consideration involved in keeping crowded resources clear... But don't do it. It wouldn't be nice:-) Barry
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 88 17:23:35 GMT From: lars@ACC-SB-UNIX.ARPA (Lars J Poulsen) To: comp.protocols.tcp-ip Subject: Re: x.25 as an internet backbone
> From lars@acc.arpa Sat Aug 6 09:35:15 1988
> Date: 5 Aug 88 20:29:51 GMT
> From: ozalp@cu-arpa.cs.cornell.edu (Ozalp Babaoglu)
> Organization: Cornell Univ. CS Dept, Ithaca NY
> Subject: x.25 as an internet backbone
> To: tcp-ip@sri-nic.arpa
>
> suppose a country (italy, to be precise) currently has a single
> internet site (in pisa) and has been registered as a top-level domain
> (domain .IT). there are three class C type IP addresses
> allocated to the country. what are some reasonable ways to structure
> subdomains in this country domain and incorporate LANs at other
> sites (cities) into the internet? the physical transport medium
> available is x.25 (both private and PDN run by the telephone company).
>
> what is the technology of choice for ethernet-x.25 gateway hardware
> and the software to do the routing and encapsulation (of IP
> packets over x.25)? any suggestions will be appreciated.
>
> ozalp babaoglu
For each campus, assume an ethernet with its own network number.
(class C may be adequate for a while). For each of these, nominate
a router with an X.25 interface to be the gateway to the outside world.
Suitable routers include Ultrix with ACC's ACP5250, SUN with SUNLINK,
VMS with Wollongong TCP/IP and ACP5250, and many otehrs as well as
standalone router boxes. The router must run EGP, ROUTE-D or similar
gateway protocol to advertize reachability.
If the private X.25 network has a DNIC and can communicate with the public
data network, then you have one X.25 world, and all X.25 should use
one network number. If not, get a network number for the X.25 network.
Since X.25 has no ARP mechanism, all routers must share knowledge of IP
address to X.25 address mappings. This means a centralized management
of each X.25 IP network. CSNET does this on a commercial basis in
the US, and it would be to your advantage to join them so that
your PTT network is joined with the X.25 part of CSNET. However, I
don't know if their fee schedule makes this practical.
Another possibility is to declare your X.25 network to be its own
IP network, and have a single gateway to the outside (via CSNET or
AC.UK or via a private arrangement with a US site) but this means you
have to have fairly sophisticated traffic analysis in the gateway
in order to charge back the international X.25 charges to the member
institutions (since they all will be charged to the gateway).
I don't know of any router equipped to do this.
Let me know how you arfe involved with the evangelism in Italy,
and contact me if I can be of more help.
/ Lars Poulsen
ACC Customer Service.
P.S.: No slight is intended of any product not mentioned above.
I have nothing against CMU TCP/IP or Hewlett-Packard.
SRI MultiNet is a fine product, and so is the ACS4020...
products mentioned above are for examples only.
My employer does not know I'm sending this ...
is that enough disclaimers ?
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 88 04:59:14 GMT From: sm.unisys.com!csun!polyslo!steve@oberon.usc.edu (Steve DeJarnett) To: tcp-ip@sri-nic.arpa Subject: nroff source for recent TCP/IP paper from Rutgers???
I recently read the paper posted by Charles Hedrick from Rutgers, and found it quite informative. I was wondering if the source (nroff or TeX) was available. It would be nice to have a printout that was more suitable for reading than a normal printout. I didn't save the author's email address, so sorry for the posting. Thanks in advance, ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 88 05:24:30 GMT From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) To: comp.protocols.tcp-ip Subject: Re: BOOTP vendor support
> *Excerpts from ext.in.tcp-ip: 5-Aug-88 Re: BOOTP vendor support David R.*
> *Conrad@terminus (517)*
> We'd also be interested in having more vendors (particularly Proteon)
> support bootp forwarding
Hear Hear! We find BOOTP very useful. It's biggest problem though is that it
requires special support in gateways to forward requests across subnets.
Either that or a server for every subnet, which is a real pain since it is
often cost prohibitive. As a campus support organization we can't afford to
put a server machine (or two for redundancy) on each net. From my experience,
it takes less than 150 lines of code or so for a fairly robust gateway
forwarder implementation. In case it helps anybody, here is most of the code
from our router implementation. Everyone's router is different of course, so I
doubt if it will 'just slip in'.
Drew
/*
* Bootstrap Protocol (BOOTP). RFC 951.
*
* 07-Oct-86 Drew D. Perkins (ddp) at Carnegie-Mellon University
* Started history.
*
**********************************************************************
*/
#include "cond/bootp.h"
#if C_BOOTP > 0
/*
* bp_input - process an incoming BOOTP server packet.
*
* dv = the device supplying the packet
* p = the supplied BOOTP packet (with offset and length adjusted to
* remove any encapsulating headers/trailers)
* sport = the UDP source port of the sender of the datagram
* saddr = the datagram's IP source address
* daddr = the datagram's IP destination address
* (These will typically be pointers into the encapsulating IP
* header preceding the RCP packet - beware!)
*
* The following consistency checks are performed on the BOOTP packet:
* - the physical length of the packet must be large enough to contain a
* minimal BOOTP header.
* If the packet is a boot request:
* - the packet must not have been through too many gateways.
* - the requestor must have waited a long enough time for service.
* If the packet checks out, the message is counted and processed
* according to the protocol.
*/
void bp_input(dv, p, sport, saddr, daddr)
struct device *dv;
struct packet *p;
short sport;
struct socket p_pkt saddr;
struct socket p_pkt daddr;
{
register struct bootp p_pkt bp;
register struct device *dvt; /* determined target device of pkt */
register struct ipmap *im; /* IP routing table entry */
register struct addmap *am; /* ARP routing table entry */
struct socket src, dest, tmp; /* src and dest of outgoing IP pkt */
short dport; /* destination UDP port */
int flag = 0; /* Have seen incoming device flag */
if (p->p_len < BOOTHEAD) { /* Packet large enough? */
profile(dv, bp_rmin);
errorlog(p, EL_BP_RMIN);
goto out;
}
bp = poff(bootp, p);
#ifdef BOOTPDEBUG
if (p->p_flag&P_TRACE) {
printf("BOOTP (%d):\r\n", p->p_len);
bp_prt(bp);
}
#endif /* BOOTPDEBUG */
switch(bp->bp_op) { /* Check opcode */
case BOOTREQUEST:
/* Only forward after some amount time */
if (ntohs(bp->bp_secs) < BOOTMINSECS) {
profile(dv, bp_rsecs);
goto out;
}
/* Prevent loops */
if (bp->bp_hops++ > BOOTMAXHOPS) {
profile(dv, bp_rhops);
errorlog(p, EL_BP_RHOPS);
goto out;
}
for (dvt=dv; flag == 0 || dvt != dv; dvt=dvt->dv_prnext[PR_IP]) {
flag = 1;
bcopy((char *)&dvt->dv_praddr[PRA_IP],(char *)&tmp, PRL_IP);
if (bp->bp_giaddr.s_addr == tmp.s_addr) {
profile(dv, bp_rloop);
errorlog(p, EL_BP_RLOOP);
goto out;
}
}
profile(dv, bp_reqcnt);
/* Fill in gateway field if empty */
if (!bp->bp_giaddr.s_addr) {
copout(&dv->dv_praddr[PRA_IP], (char p_pkt) &bp->bp_giaddr,
PRL_IP);
} else {
profile(dv, bp_rgway);
}
src.s_addr = bp->bp_giaddr.s_addr;
dest.s_addr = daddr->s_addr;
/* Check out destination address */
am = ar_map(PR_IP, (char p_pkt)daddr);
if (am == 0 || !(am->am_flag&AM_BCAST)) {
dest.s_addr = ipaddr(0xff, 0xff, 0xff, 0xff);
profile(dv, bp_rbaddst);
}
dport = UD_BOOTPS; /* Send to BOOTP Server */
break;
case BOOTREPLY:
if (!bp->bp_yiaddr.s_addr) {
profile(dv, bp_runkaddr);
errorlog(p, EL_BP_RUNKADDR);
goto out;
}
profile(dv, bp_repcnt);
dest.s_addr = bp->bp_yiaddr.s_addr;
/* Set up arp cache */
im = im_map(daddr, IM_ME);
/* If it isn't found then we got this by mistake */
if (im == 0) {
goto out;
}
dvt = im->im_dv;
ar_remap(PR_IP,(char p_pkt)&dest,(char p_pkt)bp->bp_chaddr, dvt);
src.s_addr = saddr->s_addr;
dport = UD_BOOTPC; /* Send to BOOTP client */
break;
default:
profile(dv, bp_rbadop);
errorlog(p, EL_BP_ROP);
goto out;
}
ud_output(dv, p, sport, dport, (struct socket p_pkt) &dest,
(struct socket p_pkt) &src);
return;
out:
(*(p->p_done))(p);
}
void bp_prt(bp)
register struct bootp p_pkt bp;
{
char tempa[20],tempb[20],tempc[20],tempd[20];
int i;
printf(" op: %d, hops %d, id %ld, secs %d\r\n",
bp->bp_op, bp->bp_hops, bp->bp_xid, bp->bp_secs);
printf(" htype %d, hlen %d, chaddr ",
bp->bp_htype, bp->bp_hlen);
for (i = 0; i < bp->bp_hlen; i++)
printf("%2x", bp->bp_chaddr[i]);
printf("\r\n ciaddr = %s, yiaddr = %s, siaddr = %s, giaddr = %s\r\n",
ip_fmt(&bp->bp_ciaddr, tempa),
ip_fmt(&bp->bp_yiaddr, tempb),
ip_fmt(&bp->bp_siaddr, tempc),
ip_fmt(&bp->bp_giaddr, tempd));
}
#endif /* C_BOOTP */
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 1988 21:06-EDT From: URBANIAK@G.BBN.COM To: tcp-ip@SRI-NIC.ARPA Cc: urbaniak@G.BBN.COM Subject: Ether types
per Torben Nielson's request. (that host not resolved from here.) Some Known Ethernet and IEEE802.3 "Type" Fields 6/18/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These values are managed by XEROX. Some assignments are public, others private. Current information includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960; contributions from network managers and vendors. Hex 0000-05DC IEEE802.3 Length Field (0.:1500.) 0200 Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00) 0201 Xerox PUP Address Translation (conflicts ...) (see 0A01) 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 0888 Xyplex 0900 Ungermann-Bass network debugger 0A00 Xerox IEEE802.3 PUP 0A01 Xerox IEEE802.3 PUP Address Translation 0BAD Banyan Systems 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 7000 Ungermann-Bass download 7002 Ungermann-Bass diagnostic/loopback 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics reserved 8016 Silicon Graphics XNS NameServer, bounce server 8019 Apollo DOMAIN 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 807C Merit Internodal 8080 Vitalink TransLAN III Management 809B EtherTalk (AppleTalk over Ethernet) 80DE TRFS (Integrated Solutions Transparent Remote File System) 80F3 AppleTalk Address Resolution Protocol (AARP) 8107 Symbolics Private 8108 Symbolics Private 8109 Symbolics Private 8137 Novell 9000 Loopback (Configuration Test Protocol) 9001 Bridge Communications XNS Systems Management 9002 Bridge Communications TCP/IP Systems Management FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Some Known Ethernet Vendor Addresses 8/7/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), or globally-assigned versus locally-assigned addresses, some of the known addresses do not follow the scheme. 00000C Cisco 00002A TRW 00005A S & Koch 000093 Proteon 00009F Ameristar Technology 0000AA Xerox Xerox machines 0000C0 Western Digital 0000DD Gould 000102 BBN BBN internal usage (not registered) 001700 Kabel 00DD00 Ungermann-Bass 00DD01 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines, Apollo 020406 BBN BBN internal usage (not registered) 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp, Silicon Graphics 080002 Bridge 080005 Symbolics Symbolics LISP machines 080008 BBN 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp, Silicon Graphics 080017 NSC 08001A Data General 08001B Data General 08001E Apollo 080020 Sun Sun machines 080025 CDC 080028 TI Explorer 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080045 Xylogics??? 080047 Sequent 080049 Univation 08004C Encore 08004E BICC 080068 Ridge 080069 Silicon Graphics 08006E Excelan 08007C Vitalink TransLAN III 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Global physical address for some DEC machines AA0004 DEC Local logical address for systems running DECNET Some Known Ethernet Multicast Addresses 6/18/88 Ethernet Type Address Field Usage Multicast Addresses: 09-00-09-xx-xx-xx ???? HP multicasts 09-00-2B-01-00-00 8038 DEC LanBridge Copy packets 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the designated LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-00-FF-FF AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster groups CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 88 21:59:16 GMT From: jqj@HOGG.CC.UOREGON.EDU To: comp.protocols.tcp-ip Subject: Re: Moderated Newsgroup Posting
It was clearly wrong of me to have elided an elision symbol after my quotation. However, I rather resent being called "downright dishonest." Granted that Olsen clearly believes that the problem is TCP/IP, not any incompetence of the Ultrix group, remember that he sells a product -- Ultrix -- that includes support for networking. It would seem to me that the thrust of the quotation remains that Olsen is not serious about delivering the TCP/IP based Ultrix networking that DEC advertises. Phrased differently, I believe it fair to conclude that Olsen in fact has no confidence that his Ultrix group can deliver on DEC's marketing promises. Another quotation out of context from the same source: "VAX is VMS." This discussion is rapidly shifting away from topics of interest to the TCP-IP mailing list, and to ones more appropriate to INFO-VAX.
-----------[000084][next][prev][last][first]----------------------------------------------------
Date: 7 Aug 88 23:02:44 GMT
From: torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To: comp.protocols.tcp-ip
Subject: Ether types...Would someone kindly mail me a copy of the current list of valid Ethernet types. I know it's out there somewhere and I've seen it fly by every so often. I'm sitting and looking at a dump of Ethernet packets and I'm seing a couple of strange things. Trying to find out what the packets are. Anyone happen to know if there're legitimate reasons for sending to yourself onan Ethernet? That is, Ethernet packets where the source and the destination address are identical? Seems pointless since as far as I know, you cannot read packets you yourself transmitted off of the wire..... Am I wrong? Torben
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 8 Aug 88 01:06:00 GMT From: URBANIAK@G.BBN.COM To: comp.protocols.tcp-ip Subject: Ether types
per Torben Nielson's request. (that host not resolved from here.) Some Known Ethernet and IEEE802.3 "Type" Fields 6/18/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These values are managed by XEROX. Some assignments are public, others private. Current information includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960; contributions from network managers and vendors. Hex 0000-05DC IEEE802.3 Length Field (0.:1500.) 0200 Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00) 0201 Xerox PUP Address Translation (conflicts ...) (see 0A01) 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 0888 Xyplex 0900 Ungermann-Bass network debugger 0A00 Xerox IEEE802.3 PUP 0A01 Xerox IEEE802.3 PUP Address Translation 0BAD Banyan Systems 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 7000 Ungermann-Bass download 7002 Ungermann-Bass diagnostic/loopback 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics reserved 8016 Silicon Graphics XNS NameServer, bounce server 8019 Apollo DOMAIN 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 807C Merit Internodal 8080 Vitalink TransLAN III Management 809B EtherTalk (AppleTalk over Ethernet) 80DE TRFS (Integrated Solutions Transparent Remote File System) 80F3 AppleTalk Address Resolution Protocol (AARP) 8107 Symbolics Private 8108 Symbolics Private 8109 Symbolics Private 8137 Novell 9000 Loopback (Configuration Test Protocol) 9001 Bridge Communications XNS Systems Management 9002 Bridge Communications TCP/IP Systems Management FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Some Known Ethernet Vendor Addresses 8/7/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion