|
|
ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for August 1986 (65 messages, 32848 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/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: Fri, 1-Aug-86 16:13:58 EDT From: bjp@MITRE-BEDFORD.ARPA.UUCP To: mod.protocols.tcp-ip Subject: The big search for companies who sell DDN gateways
I am looking for product information on Gateway products that can
interface with DDN X.25 and an ethernet local area network. The
ideal product would interface with DDN X.25 standard and IEEE 802.3.
The internet protocol (IP) would use the "Revised Internet Security
Option (IPSO)". Please send me any information on companies you
know about that sell DDN X.25 gateways or if you represent a firm
whose product line includes such a product, please send me information
on your gateway products.
Mail address:
Barbara J. Pease
Mail Stop K326
MITRE Corp.
Burlington Rd.
Bedford, MA 01730
Electronic Mail: bjp@mitre-bedford.arpa
If you could send me something soon, It would be a big help.
bj Pease
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Mon, 4-Aug-86 09:02:59 EDT From: Jschmidt%cda-pdp01@AMC-HQ.ARPA To: mod.protocols.tcp-ip Subject: [bjp%mitre-bedfo: The big search for companies who sell DDN gateways]
Communication Machinery Corp. (CMC) has a gateway that interfaces DDN
X.25 to IEEE 802.3. Their product designation is DRN-3200.
Their address is: 1421 State St.
Santa Barbara, CA 93101
(805) 963-9471
Jeff Schmidt
jschmidt@amc-hq
----- Forwarded message # 1:
Received: From Sri-Nic.ARPA by AMC-HQ via smtp; 1 Aug 86 15:35 EDT
Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Fri 1 Aug 86 12:21:08-PDT
Full-Name: Pease
Message-Id: <8608011921.AA13535@mitre-bedford.ARPA>
Organization: The MITRE Corp., Bedford, MA
To: tcp-ip%sri-nic.arpa@AMC-HQ.amc
Cc: bjp%mitre-bedford.arpa@AMC-HQ.amc
Subject: The big search for companies who sell DDN gateways
Date: Fri, 01 Aug 86 15:21:35 -0500
From: bjp%mitre-bedford.arpa@AMC-HQ.amc
Via: amc-hq; 1 Aug 86 16:17-EDT
Via: Darcom1; 1 Aug 86 17:11-EDT
I am looking for product information on Gateway products that can
interface with DDN X.25 and an ethernet local area network. The
ideal product would interface with DDN X.25 standard and IEEE 802.3.
The internet protocol (IP) would use the "Revised Internet Security
Option (IPSO)". Please send me any information on companies you
know about that sell DDN X.25 gateways or if you represent a firm
whose product line includes such a product, please send me information
on your gateway products.
Mail address:
Barbara J. Pease
Mail Stop K326
MITRE Corp.
Burlington Rd.
Bedford, MA 01730
Electronic Mail: bjp@mitre-bedford.arpa
If you could send me something soon, It would be a big help.
bj Pease
----- End of forwarded messages
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Mon, 4-Aug-86 22:30:20 EDT From: gds@SRI-SPAM.ARPA (The lost Bostonian) To: mod.protocols.tcp-ip Subject: Re: Lisp machines don't receive network level broadcasts right, causing net mayhem
From: jnc@brubeck.proteon.com
Hosts shouldn't be forwarding packets (or sending redirects)
anyway. It is a complete bug that the LISP machine are even presuming
to do either.
I agree there is a bug with broadcast packets. But... if a non-gateway
host receives a non-broadcast packet that is not for it, why shouldn't
it BOTH forward it and send a redirect? How is the sender to know that
it is sending packets to the wrong place?
Why not use the icmp parameter problem message? Rather than dropping
the packet on the floor, or worsening the problem by forwarding the
packet or sending a redirect (question: what does the host redirect
to?), it seems a reasonable way to let the sender know about the
problem, and it costs the same as sending a redirect. All the ip
implementations will have to be taught to do something with the
parameter problem type, besides just accept it.
--gregbo
-----------[000003][next][prev][last][first]----------------------------------------------------
Date: Tue, 5-Aug-86 14:04:12 EDT
From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To: mod.protocols.tcp-ip
Subject: Re: RING vs. ETHER - Theory and practice.
Right, I was referring to selective ACK's; i.e. a bit vector or an
array of ack ranges or something which allows you to say 'I did get this
stuff but not that' and describe holes, etc. (Just out of interest, protocol
archaelogists and old fogies may remember that the Xerox PUP BSP had such
ACK's!)
As far as the whole quesion of engineering tradeoffs on ACK's go,
there are a lot of different interacting factors and criteria. The two big
questions seem to be whether to ack packets or bytes, and whether to have
single or multiple ack's. (Following is expansion for those who aren't
familiar with the tradeoffs.)
The correct answer seems to be conditioned by a couple of design
criteria. The first is what effective data rates you expect to see, and the
second is what packet loss rate the system has. If you want high data rates,
either a) the net has to have an extremely low packet loss rate, or b) you
need a smarter acknowledgement strategy. In case b), it would seem that
since the overhead of processing ack's on a per byte basis is too high, the
thing to do is to do ack's on a per packet basis. It seems that in a lossy
system, ack'ing on a per byte basis (which allows retransmissions to be
coalesced) is the right thing for slow connections.
I'm not sure what the right answer is. I really don't go back far
enough to know what the discussions in the early days of TCP ('76 or so, I
would imagine) made of all the issues and tradeoffs. I talked to Dave Clark,
who does remember, and in retrospect the problem was fairly fully
understood; the impact of packet losses on high data rates transfers was
clear (although perhaps the degree to which a single loss could affect very
high speed transfers was not appreciated). Apparently, the system was
assumed to have a low loss rate, modulo congestion, which was supposed to be
handled via a separate mechanism. (The fact that the original design of this
mechanism didn't work and a new one has yet to be created is the cause of a
lot of our current problems.) The per-byte acks were part of the flow
control, which wanted to be on a per byte basis.
I guess we won't really know if the right decision was made until
the system as a whole either is made to obey the design criterion that is
currently being violated (low loss rates) or it proves impossible to meet
that constraint. In the latter case, a different mechanism would be
indicated.
It seems to be another case of the 'simple safety net' philosophy;
as long as some mechanism is not used much, it doesn't matter if the design
is optimal: it's used so rarely. Ack's are in precisely this boat: if you
don't lose many packets, you don't need a sophisticated ack strategy.
Noel
-------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Tue, 5-Aug-86 14:28:44 EDT From: mcb%lll-tis-b.ARPA@LLL-TIS-GW.ARPA (Michael C. Berch) To: mod.protocols.tcp-ip Subject: Protocol validation suites?
Forgive me if this topic has been covered extensively here, but we
have a program sponsor (military) who is interested in a test suite
for validation and/or benchmarking of their vendor's DDN protocol package.
They are concerned primarily about the efficiency of the DDN X.25
implementation; my interest is more along the lines of IP, TCP, and the
application-level protocols. Ideally, there would be suites for both.
Any information would be greatly appreciated.
Michael C. Berch
Control Data Corp. / Lawrence Livermore Natl. Laboratory
ARPA: mcb@lll-tis-b.arpa
UUCP: {ihnp4,dual,sun}!lll-lcc!styx!mcb
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 1986 07:31-EDT From: CERF@A.ISI.EDU To: JNC@XX.LCS.MIT.EDU Cc: ron@BRL.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: RING vs. ETHER - Theory and practice.
Noel, I don't think I could reconstruct all the paths we took in examining different ACK schemes, but I do recall that we examined the selective ack idea in considerable detail. One of the "criteria" which caused difficulty had to do with disorderly arrival and with the complexity of maintaining a kind of scrolling status of which bytes had been received and which had not since the accounting (sequence numbering) was byte oriented. There were many reasons for that decision but chief among them was uncertainty as to maximum packet sizes and the need for an indeterminate number of fragmentation steps - the hierarchical numbering plans suffered with complexity compared to the simplicity of sequential, byte-oriented numbering. As the accounting unit gets larger, selective acking becomes easier to account for and, indeed, you find it in various link level or even transport level protocols which are block rather than byte oriented. It is certain that lack of congestion control and integrity enforcement produces very serious performance deficits under some conditions- all the flow control in the world won't help if packets are discarded for some other reason than the source's transmission rate. I agree with you that the performance issues deserve very careful attention; we need to learn from the mistakes we may have made or, at the least, treat all our experiences in complex internetting as the results of endless experiments intended to guide us in developing better protocols. Vint
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 86 16:24:00 PST From: <gary@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: m/1822 on SUN3's
ACC is requesting information on any user which is using our m/1822 interface board with the SUN 3 VME/Multibus adapter. What you experience has been and what address/switch seetings have you found acceptable. Please address your responses to me. Gary ------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 6-Aug-86 20:24:00 EDT From: gary@ACC.ARPA To: mod.protocols.tcp-ip Subject: m/1822 on SUN3's
ACC is requesting information on any user which is using our m/1822 interface board with the SUN 3 VME/Multibus adapter. What you experience has been and what address/switch seetings have you found acceptable. Please address your responses to me. Gary ------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 86 08:08:00 PST From: <gary@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: updating Customer Service files
ACC is in the process of updating it's customer files. Towards that end I am requesting that all users of our HDH products please send me a net message with your host number, type of host, and o/s. This way ACC can notify you directly regarding any firmware/operating system updates which may impact your system. Thanks for the assistance, Gary Krall ------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-Aug-86 08:33:00 EDT From: eichelbe@NADC.ARPA To: mod.protocols.tcp-ip Subject: Domains: when do they "kick" in?
I am interested in knowing when the full use of domains will begin and if/when (how long do I have before) mail systems that do not support domains will stop working. Thanks. Jon Eichelberger eichelbe@NADC.ARPA
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 1986 08:33:00-EDT From: eichelbe@NADC To: info-unix@BRL, tcp-ip@sri-nic Subject: Domains: when do they "kick" in?
I am interested in knowing when the full use of domains will begin and if/when (how long do I have before) mail systems that do not support domains will stop working. Thanks. Jon Eichelberger eichelbe@NADC.ARPA
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-Aug-86 12:08:00 EDT From: gary@ACC.ARPA To: mod.protocols.tcp-ip Subject: updating Customer Service files
ACC is in the process of updating it's customer files. Towards that end I am requesting that all users of our HDH products please send me a net message with your host number, type of host, and o/s. This way ACC can notify you directly regarding any firmware/operating system updates which may impact your system. Thanks for the assistance, Gary Krall ------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Thu, 7-Aug-86 21:00:15 EDT From: karn@MOUTON.BELLCORE.COM (Phil R. Karn) To: mod.protocols.tcp-ip Subject: Computerworld article on TCP/IP vs OSI
I wonder if anyone else saw the article "OSI Substitute Lures Net Users" in the July 28, 1986 issue of Computerworld. The article begins as follows: "Business users eager to implement multivendor networks are increasingly turning to an alternative that already offers much of the networking versatility only promised by the Open Systems Interconnect protocols from the International Standards Organization. "According to user and industry sources, the alternative, called Transmission Control Protocol/Interconnect [sic] Protocol, or TCP/IP, provides an array of low-level networking functions for more than 50 vendors' systems..." And a few notable quotes from the rest of the article: "We're aware of what's going on in the OSI world, but the protocols are just not a reality for the kinds of computer applications we're doing. In terms of functionality, OSI is currently where TCP/IP was in 1980." (Tom Jacobson, director of communications for Minnesota Supercomputer Center, Inc. in Minneapolis). "I recently got into an argument with a National Bureau of Standards representative who said that OSI will supersede TCP/IP. Given the rate at which manufacturers are shipping TCP/IP, by the time OSI arrives, there will be a lot of people who will decide that don't need it. They won't drop a de facto standard just because the 'real' standard is here." (Harvey Freeman, vice president of Architecture Technology, Inc. in Minneapolis). "People thought that TCP/IP would fade and die when OSI was ready; instead, the protocols have gained even wider acceptance this year." (William Carrico, president of Bridge Communications, Inc.)
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Fri, 8-Aug-86 07:09:01 EDT From: ROKI@D.ISI.EDU To: mod.protocols.tcp-ip Subject: Wrong TCP checksum computation when IP Source Route Option is specified
Folks,
Following is a short description of a problem which seems to be a bug in
the TCP-IP code at D.ISI.EDU [10.0.0.27] (Tops20) concerning the computation
of a wrong TCP checksum when an IP Source Route Option is specified.
While the fact that a problem exists has been evident (after exchanging a
number of correct (!) packets) in each TCP connection from DFVLR2 [128.7.0.2]
via DFVLR4-X25 [14.0.0.16] (specified as IP Source Route Option) to
D.ISI.EDU [10.0.0.27], it was much more difficult to discover the bug.
Since this problem might occur on other TOPS20 machines as well, I am
sending this message not only to the host administrator of D.ISI.EDU, but
to the TCP-IP and INENG-TF list as well.
INTERNET Configuration:
----------------------
To route packets from the (SATNET isolated) DFVLR-net [128.7.x.x] to
D.ISI.EDU [10.0.0.27] through the PDN [14.x.x.x] and to get packets back
on the same path via the BBN-VAN-GW [14.0.0.10] and DFVLR4-X25 [14.0.0.16],
in the current (poor) routing situation, the local VAN-GW (DFVLR4-X25),
has to be specified as an IP Source Route Option by an user on the DFVLR-net.
DFVLR2 DFVLR4-X25 BBN-VAN-GW D.ISI.EDU
[128.7.0.2] [128.7.0.4,14.0.0.16] [14.0.0.10,10.3.0.40] [10.0.0.27]
DFVLR-net ! PDN ! ARPANET
^
Monitoring
Fortunately D.ISI.EDU uses the specified IP Source Route Option [14.0.0.16]
even in its reply packets and therefore after opening an TCP connection to
D.ISI.EDU packets were routed back on the same path via DFVLR4-X25 to DFVLR2
and received there correctly.
However after receiving a number of packets with a correct TCP checksum at
DFVLR2, only packets (retransmissions) with a bad TCP checksum were
received and therefore discarded, so the connection was blocked (no more
data exchange).
After implementing some monitor tools behind the X.25 interface at
DFVLR4-X25 (monitoring the packets as transmitted over X.25 PDN), I found
that those packets look fine (no corruption), but already contain a wrong
TCP checksum.
TCP-checksum:
------------
As you know the TCP checksum also covers a 96 bit pseudo header which contains
the Source Address, Destination Address, Protocol and TCP length.
When recomputing the TCP checksum (TCP header + data + pseudo header) using
a pseudo header of
10 0 0 27
128 7 0 2
0 6 length
I got another TCP checksum as contained in the packet. Since the TCP header
and the data looked fine, I played around with some possible computations of
modified TCP pseudo headers and finally (surprise !) I got the same (wrong)
TCP checksum as transmitted in the packet, when using a Destination Address
of 14.0.0.16, which is the Destination Address in the IP Header before the
packet reaches DFVLR4-X25 [14.0.0.16] (IP Source Route Option), but must
never be specified as the Destination Address in the TCP Pseudo Header.
Thus with the following TCP pseudo header:
10 0 0 27
14 0 0 16 (instead of 128 7 0 2)
0 6 length
I computed the TCP checksum contained in the packet.
Assuming that no intermediate host or gateway between D.ISI.EDU and
DFVLR4-X25 recomputes the TCP checksum, I guess that the wrong TCP checksum
is already computed at the source (D.ISI.EDU).
NOTE: Before receiving packets with this bad TCP checksum (14.0.0.16 as
Destination Address in TCP pseudo header), I am receiving packets
with correct TCP checksum (128.7.0.2). I have no idea what causes this
switch, however I have found packets (in which 14.0.0.16 is used to
compute the TCP checksum) only in packets with an ODD (!) number of data
bytes.
Monitoring Dump:
---------------
Herewith I enclose a dump of two packets (both might be retransmissions),
which were received immediately one after the other over an virtual circuit
through PDN (X.25) from the BBN-VAN-GW at DFVLR4-X25 (dumped immediately
after the X.25 interface).
While the first packet (IP Source Route specified, ACK only, 52 bytes, 0 data
bytes) contains a correct TCP checksum (assuming 128.7.0.2 as destination
in the TCP pseudo header), the TCP checksum computation of the second packet
(IP Source Route, 53 bytes, 1 data byte (@)) seems to use 14.0.0.16 as the
destination address in the TCP pseudo header. A bad TCP checksum was
therefore computed at the destination DFVLR2 [128.7.0.2] and the packet
was discarded.
Good packet (IP Source Route specified, ACK only, 52 bytes, 0 data bytes):
-------------------------------------------------------------------------
72 0 0 52 83 135 0 0 58 6 98 125 10 0 0 27 14 0 0 16
VIHL TOS Length Ident. Fl/Frag TTL Pro HChksum Source Destination
131 11 8 10 0 0 27 128 7 0 2 0 0 23 16 0 52 151 0 203
SRR len poi route (source) (destination) pad !SPort DPort Sequence Numb.
4 165 127 231 80 16 3 190 87 237 0 0
Acknowl. number Offs ACK Window Chksum Urg.Poi
TCP OK
TCP Pseudo Header:
10 0 0 27 128 7 0 2 0 6 0 20
Source Address Destin. Address Zer PTCL length
Bad packet (IP Source Route specified, ACK only, 52 bytes, 0 data bytes):
-------------------------------------------------------------------------
72 0 0 53 79 175 0 0 54 6 106 84 10 0 0 27 14 0 0 16
VIHL TOS Length Ident. Fl/Frag TTL Pro HChksum Source Destination
131 11 8 10 0 0 27 128 7 0 2 0 0 23 16 0 52 151 0 202
SRR len poi route (source) (destination) pad !SPort DPort Sequence Numb.
4 165 127 231 80 24 3 190 137 222 0 0 64 (0)
Acknowl. number Offs ACK Window Chksum Urg.Poi !Data
PSH TCP BAD,
should be
23 229
Assumed TCP Pseudo Header:
10 0 0 27 14 0 0 16 0 6 0 21
Source Address Destin. Address Zer PTCL length
should be
128 7 0 2
Debugging:
---------
For a debugging session similar packets should be reproduceable. Does anybody
has seen similar problems ? (Perhaps somebody could try !?)
Thanks for any comments and fixing the problem.
Best regards,
Carl-H. Rokitansky (Roki)
--------------------------
PS.: Currently I'm routing my packets by means of a cludge (assignment of
[14.0.0.16] to DFVLR2 !!)
-------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Fri, 8-Aug-86 19:17:00 EDT From: Kelley.pa@XEROX.COM To: mod.protocols.tcp-ip Subject: Re: Getting machine readable copies of protocol specs
The X.400 series of documents done in IFIP WG 6.5 contained integrated multi-font text and graphics done on a Xerox Star. They were probably not distributed on the ArpaNet at the time simply because there was no easy way to convert them to a readable message format. Furthermore, there was no other electronic mail list for discussion of the standard by members of the committee because the necessary gateways between the members' electronic mail boxes did not exist. -- kirk
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Sat, 9-Aug-86 19:15:00 EDT From: medin@ORION.ARPA (Milo S. Medin, NASA ARC Code ED) To: mod.protocols.tcp-ip Subject: SUN and Subnets
Hi folks. I'm working on building some IP based networks for NASA, and
in talking with several sites, I've found that many would like to shove
an additiional ethernet board into a SUN fileserver, and gateway the traffic
from the busy local ethernet to a 'backbone' type ethernet. Further, a couple
places are using Sun's SUNlink package running over 9600 baud synch. lines
linking a couple machines out in remote locations, and would prefer to
continue using it. The problem I've run into is that SUN doesn't support
subnetting. We subnet here at Ames, and have some SUNs in the local
internet, but none as gateways. We can deal with them because our IP
gateways run with the 'arphack' and so we fool the SUNs into working
into the subnet structure of the local network. But you can't deal with
subnetting if the gateway doesn't know about it. So I'm faced with swapping
out all the SUN machines being used as gateways with a 'real' gateway, or
using bunches of Class C nets here and there. Using a more capable
gateway is probably in the future for all the long haul links, but
the campus LAN's will probably continue to use SUN fileservers as gateways
simply because they may have a lot of diskless SUN clusters.
When I asked my SUN rep. about subnetting, he said that SUN OS 4.0 might
have it, and that would be released in the Jan./Feb. '87 timeframe, but would
make no committments. Other people I know who have asked got no commitment
from SUN at all. Further, my SUN rep. mentioned that subnetting requires
some non-trivial changes in NFS. I can't understand why this would be the
case. I'm aware that various sites have patched up SUN kernels
to run with subnets, and that it was fairly easy if you had source code.
Many of the sites I talk to however, would really not like for
me to come in with a special set of .o files and start messing
with their working vanilla SUN kernels unless I absolutely had to.
I can't figure out why SUN is being so tardy about implementing
subnetting. RFC 950 has been out for some time, and considering
the amount of business they do with universities, I would think many
people would be grateful for some relief in this area. Has anyone
out there gotten a committment from SUN to implement subnetting,
or gotten any reason why its hard for them to do so? It sure would
be easier on the Internet community if they did so. Anybody from
SUN care to comment?
Milo Medin
NASA Ames Research Center
Moffett Field, CA
Internet: medin@ames.arpa
UUCP: {seismo,amdcad}!nike!medin
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Sat, 9-Aug-86 20:48:36 EDT From: rick@SEISMO.CSS.GOV (Rick Adams) To: mod.protocols.tcp-ip Subject: Re: SUN and Subnets
Back in March I got a pseudo answer out of Sun. They would like to have it in the 3.2 release, but it would probably break the binary backwards compatibility with 3.0, so they would probably have to wait for 4.0. From the sound of it 3.2 should really be called 4.0, and 4.0 shold be called 5.0. It seems to be more of a marketing decision than an engineering decision. I'd gladly accept the tiny backwards incompatibility as I'm sure most people would. ---rick
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Sat, 9-Aug-86 23:41:49 EDT From: karels@MONET.BERKELEY.EDU (Mike Karels) To: mod.protocols.tcp-ip Subject: Re: SUN and Subnets
Berkeley has been using Suns on subnetted networks and (sigh) as gateways for nearly two years. We added subnet support before we even had source code by substituting 1 kernel source file and 2 header files, plus ifconfig and routed. Unfortunately, several Sun changes have made this harder to support, and the subnet scheme used is the old Berkeley scheme which supports only 8-bit subnet fields with the high bit set. I have been told by Sun systems people that subnet support will be in the 4.0 release, but that's not as helpful as I would like. I have been tempted to figure out how to package and distribute subnet support for Suns, but haven't taken the time to do so. Perhaps I could convince someone else working with Suns at Berkeley to package things up if a few sites could test it. Mike
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Sun, 10-Aug-86 02:13:29 EDT From: chris@gyre.umd.edu (Chris Torek) To: mod.protocols.tcp-ip Subject: Re: SUN and Subnets
We just insist on source, so that we can fix things like that (and like the lack of checksumming in NFS) ourselves. (We seem already to have been bitten several times by Ethernet bit rot: `mysterious' NFS errors that are not reproducible. There was no other disk activity at the time, so this is not the namei bug.) Steve Miller dropped the 4.3 TCP into our 3.0 kernels. Aside from one locally-introduced bug, it has been working well for some time. (The local bug was fixed a few days ago.) Once the file servers are stable---we have been suffering with disk problems (another local hack, this time in hardware)---we might consider distributing the code; but we will likely have to require both 4.3 and 3.0 source licenses (alas!). Chris
-----------[000019][next][prev][last][first]----------------------------------------------------
Date: Sun, 10-Aug-86 16:45:49 EDT
From: paul@UMIX.CC.UMICH.EDU ('da Kingfish)
To: mod.protocols.tcp-ip
Subject: Re: SUN and Subnetsmaybe Sun would be a little quicker if they realized that one of their competitors, Apollo, has a very nice tcp release that includes subnetting. we are running it here now at Michigan. --paul
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-Aug-86 09:08:38 EDT From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) To: mod.protocols.tcp-ip Subject: subnetting on Suns
Simple-minded subnetting is very easy to do. It requires slight
changes to in.h and in.c. You can use in.c from any 4.2 system. Sun's
is not special. In addition, inet_lnaof and inet_netof need to be
fixed in a handful of utilities. We did this without sources.
Sun claims that they are not doing subnetting because it will break
some of the extra-cost networking options, which they get from 3rd
parties and don't have source to. I find that hard to believe, since
such code should call common kernel routines to do all routing
computations. But it wouldn't be the first time programmers wrote
code that did something they shouldn't, so I can't judge for sure.
Here is a copy of a message I sent to somebody else. Unfortunately,
our changes may be a bit too simple-minded. In trying to keep the
number of changes to a minimum, I suspect we have missed some
utilities. Any utilities that broadcasts may have to be changed.
E.g. rwho and routed. We don't use those. Ideally route and
netstat should also be changed. If you have source, you can just fix
inet_lnaof and inet_netof in the C library and reload everything.
(The patches are the same as to in_lnaof and in_netof, shown below.)
When you do this, you should also set ipforwarding to 0 on every
machine on your net. You can do this in adb:
cp /vmunix /vmunix.OLD
adb -w /vmunix
ipforwarding/W 0
^D
Make sure the /W is upper case. It should say 1 --> 0. The subnet
patch may introduce disagreements as to what the broadcast address
is. This can cause chaos. Turning off forwarding, except on actual
gateways, can make things a lot better. They actual gateways
should have some repair work done to in_forward, so that they
don't forward packets with bogus broadcast addresses. I suggest
throwing away any packet that matches your class B address, and
whose low-order byte is 0 or 255. Also any address whose first
byte is 127 or 255. But others have done more work on this than I
and probably have better filters.
You need to decide what you want your broadcast address to be. 4.2 and
the Sun kernel use the convention that the broadcast address uses a host
number of 0. The newest convention, implemented in 4.3, uses a host
number of -1, i.e. 255. The standards were only changed recently, so
must vendors have not caught up. Consider our network, which is a class
B network, 128.6. On subnet 4, there are the following possible
broadcast addresses:
128.6.0.0 - used by 4.2
128.6.4.0 - used by 4.2 if you install subnets
128.6.255.255 - used by 4.3, I think
128.6.4.255 - used by 4.3 with subnets turned on, I think
255.255.255.255 - not used by any, but recognized by Sun and 4.3
When you enable subnets, the subnet number becomes in effect part
of your network number. Thus the network number is 128.6.x, not
just 128.6. So the broadcast address ends up having the subnet
number as part of it.
Now, the problem is that the Suns are set up such that every machine
on the network, including non-Suns, must agree on the broadcast
address. Otherwise there will be chaos and your network will be
flooded with spurious packets, causing all of your machines to become
unusable. By far the simplest approach is to use a broadcast address
of 128.6.4.0. The standards documents, and I think 4.3, all do imply
that the subnet number should be included in the broadcast address.
128.6.4.255 would in fact be better, but it is harder to do without
source, and is going to cause trouble until everybody updates to the
new conventions (possibly including changes to the Sun ROM's).
Nevertheless, we decided to use 128.6.0.0. We don't have as much
control over the network as I would like, and I was worried that
somebody would put up standard (non-subnet) Sun software on some
machine without talking to me. Thus it seemed safer to use a subnet
address that would be compatible with unmodified software. This patch
is possible, but not easy, without source.
I believe the following instructions will suffice to allow the 128.6.4.0
type broadcast address without source. A patch to use 128.6.0.0
type broadcast address is a bit more complex.
It is easiest to do this patch by using a source version of the module
in.c. I am including the change to in.h and in.c. MYSUBNET and possibly
the masks in in.h. However if you change the masks, some of the binary
patches may not work.
Anyway, here is what to do:
Use this version of in.c and in.h in building your kernel. I
trust you know enough about building it to make this work
without more detailed instructions.
There are patches to umount and ypbind necessary. If you have
source, just make the same patches as in in.c to the
library routines inet_netof and inet_lnaof in libc.a,
and rebuild umount and ypbind. If you don't, the following
will give reasonable approximations. They treat all
addresses as class C. Since umount and ypbind should only
be seeing packets from a local host, that is a reasonable
approximation. This is for version 3.0.
change 660e to 602c at the following address
sun 3 sun 2
umount 3f5a 3f72
ypbind 3b42 3b42
It is critical to update /etc/umount on *every* client
at the same time.
There are patches to boot necessary. If you have source,
you need to patch in_lnaof and in_broadaddr in the obvious
way. If not, then again we have an approximation based
on the assumption that boot is only going to deal with
local hosts. In /tftpboot, change ndboot.sun[23].pub[01]:
sun3 sun2
change 660a to 6024 at 5514 5662
change 6610 to 6650 at 5558 56a6
In /pub/boot, make the corresponding changes, except
that the addresses are 90000 (hex) higher. You may have
to do installboot, or patch other copies of boot,
depending upon your machines and configurations. If you
have source, you will need to change in_lnaof and
some name like in_isbroadcast.
Here are the changes to in.c
....
in_netof(in)
struct in_addr in;
{
register u_long i = ntohl(in.s_addr);
/* 6 SUBNET hack */
if ((i & SUBNETMASK) == MYSUBNET)
return (((i)&SUBNETNET) >> SUBNETSHIFT);
/* end SUBNET hack */
if (IN_CLASSA(i))
return (((i)&IN_CLASSA_NET) >> IN_CLASSA_NSHIFT);
...
in_lnaof(in)
struct in_addr in;
{
register u_long i = ntohl(in.s_addr);
/* 6 SUBNET hack */
if ((i & SUBNETMASK) == MYSUBNET)
return ((i)&SUBNETHOST);
/* end SUBNET hack */
if (IN_CLASSA(i))
return ((i)&IN_CLASSA_HOST);
In in.h, add the following. Use your own net number for MYSUBNET.
/* 6 subnet - this implementation hardwires the parameters here
* instead of using settable masks, etc., as 4.3 does */
#define MYSUBNET 0x80060000
#define SUBNETMASK 0xffff0000
#define SUBNETNET 0xffffff00
#define SUBNETSHIFT 8
#define SUBNETHOST 0x000000ff
-------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Mon, 11-Aug-86 09:49:57 EDT From: steve@brillig.umd.edu (Steve D. Miller) To: mod.protocols.tcp-ip Subject: Re: SUN and Subnets
I've heard a lot of things from a lot of people, and have some things
to say on my own. Let's see if I can't make a stab at answering some
of the questions here...
In the first article in this discussion, Milo Medin (medin@ames) says:
When I asked my SUN rep. about subnetting, he said that SUN OS 4.0
might have it, and that would be released in the Jan./Feb. '87
timeframe, but would make no committments. Other people I know who
have asked got no commitment from SUN at all. Further, my SUN rep.
mentioned that subnetting requires some non-trivial changes in NFS.
I can't understand why this would be the case.
OK. From what I have heard, Sun is trying to move to a 4.3BSD networking
base with the 4.0 release. I have talked to (a) some people at a Sun/LMI
NFS conference held in Boston in April and (b) one of the people supposedly
working on it, and unless I have grossly misunderstood something I believe
that this is indeed the case. The timeframe for the release sounds right
to me; the 3.0 release is slated for October. Again, no commitments...but
I did it myself and didn't think it was too hard. I didn't even have a real
understanding of the networking code at the time I did it and I'm sure that
the Sun people do, so they should have even less of a problem.
Sun said at the NFS workshop that they were trying to get rid of ND,
and that NFS was going to undergo a protocol rollover with the 4.0 release.
I'm sure that NFS will need a lot of work to allow things like swapping,
but I *know* that NFS version 2 (the one running in 2.0 and 3.0) works
with little or no changes on top of a subnet-based kernel. I *ran* it
on top of one (see below). If there's a problem, I'd love to hear what
it is so I can fix it...but I think the rep is wrong on this one. The
only thing that comes to mind at all is that the kudp_fastsend() routine
used to get kernel RPC/UDP packets onto the wire as fast as possible
takes a number of liberties (like no checksums) with the UDP/IP output
routines and might well need a rewrite for subnets. Commenting it out
works just as well, though...and I confess that's what I did.
In another article on the subject, Mike Karels (karels@monet.berkeley.edu)
says:
I have been tempted to figure out how to package and distribute
subnet support for Suns, but haven't taken the time to do so.
Perhaps I could convince someone else working with Suns at Berkeley
to package things up if a few sites could test it.
You've got yourself a volunteer. I don't know how useful I'd be, but I
can try to make sure that the stuff works for gatewaying. There's a room
here that could stand to be its own network; now if I can just convince my
bosses...
In yet another article, Chris Torek (chris@mimsy.umd.edu) says:
Steve Miller dropped the 4.3 TCP into our 3.0 kernels. Aside from
one locally-introduced bug, it has been working well for some time.
(The local bug was fixed a few days ago.) Once the file servers are
stable---we have been suffering with disk problems (another local
hack, this time in hardware)---we might consider distributing the
code; but we will likely have to require both 4.3 and 3.0 source
licenses (alas!).
Well, I haven't really done all that yet. I had all of the 4.3BSD (beta!)
networking code, including XNS and a protocol-independent version of NFS, in
a local kernel based on Sun 2.0. It ran subnets to the same extent as the
4.3BSD beta release, and NFS didn't hiccup at all. As I said though, I did
comment out the one (relatively small) piece of code that did the fastsend
stuff. I will probably start work on the 3.0-based version in the next
week or two, and we will probably let it out (with licensing restrictions
like I stated above) once it seems stable. I don't know if "distribute"
is the right word...
-Steve
Spoken: Steve Miller ARPA: steve@mimsy.umd.edu Phone: +1-301-454-1516
CSNet: steve@umcp-cs UUCP: {seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Wed, 13-Aug-86 05:03:40 EDT From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) To: mod.protocols.tcp-ip Subject: Sun subnetting
Scott Brim at Cornell has pointed an error in my instructions for installing subnetting in Suns. I suggest that you turn off ipforwarding. I gave a way to do this in adb. However I used the wrong letter. What I suggested would be harmless, and might even have some sensible applicatoin, but wasn't what I had intended. Let me try again: cp /vmunix /vmunix.OLD adb -w /vmunix _ipforwarding?W 0 ^D Did I get it right this time? This changes the copy of /vmunix on disk. It is also possible to change the incore copy, but it is probably easier just to do this and then reboot. Actually, since subnetting is going to require you to rebuild the kernel anyway, it might be better to patch ip_input.o. That way, any time you build a kernel you get the right thing. Otherwise you have to apply the patch to /vmunix every time you build a new kernel. In /usr/sys/OBJ you should find a file ip_input.o. cd /usr/sys/OBJ [or wherever you have the object files] cp ip_input.o ip_input.o.OLD adb -w ip_input.o _ipforwarding?W 0 ^D Now rebuild the kernel. -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 13 Aug 1986 23:24:15 CDT From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: weaber@AFSC-SD.ARPA Subject: [AFDDN.TCP-IP@GUNTER-ADAM.ARPA: Re: VAX IP/TCP]
Oops! I meant this to go out the first time. Anybody know a good typing
instructor.
---------------
Date: 13 Aug 1986 23:22:07 CDT
Subject: Re: VAX IP/TCP
From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To: Douglas M. Olson <dolson@ADA20.ISI.EDU>
cc: AFDDN.TCP-IP@GUNTER-ADAM.ARPA
In-Reply-To: (Message from "Douglas M. Olson <dolson@ADA20.ISI.EDU>" of 18 Jul 1986 13:13:22 PDT)
Doug,
The real solution to support the large number of users you talked about
would be to support TCP/IP on your ethernet and use multiple IP gateways.
PAD is a generic term for the function of turning certain data streams
into X.25 packets for transmission through a packet network, and then
turning the packets back into the data stream on the other side of the
network. The purpose is to make the network transparent to the devices
generating the data streams. The primary use for PADs is to support
synchronous terminals across packet nets. This nutshell description doesn't
cover every aspect of PADs; its just info. The bottom line is PADs are not the
solution you need.
I recently sent you a note on the uVAX configuration you were considering.
Again, the bottom line of all I said was that I don't think a uVAX can handle
the simultaneous traffic you suggest. I would probably take two to handle
60 connections and even then I think that might be pushing it since every user
will be Telneting into the uVAX and then DecNetting out to their real host in
the Cluster. FTP users will have to transfer files onto the uVAX, then get
them across the ethernet. The same will probably be true of electronic mail
using SMTP; unless there's a package for the uVAX that will forward mail
through the ethernet. If anybody out there in TCP/IP land knows of software
to make the uVAX a cleaner interface, please let me know.
I have assumed that you are running DECNET in your Cluster. I think you
should consider using TCP/IP and use gateways into the Milnet. However,
I've heard it mentioned that some folks out at JPL are working on what
has been termed a DDN/Decnet gateway. I assume such a device would translate
between the ARM protocols and Decnet and would be transparent. Again, does
anybody else have more info?
Darrel Beach
-------
-------
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Thu, 14-Aug-86 00:24:15 EDT From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: mod.protocols.tcp-ip Subject: [AFDDN.TCP-IP@GUNTER-ADAM.ARPA: Re: VAX IP/TCP]
Oops! I meant this to go out the first time. Anybody know a good typing
instructor.
---------------
Date: 13 Aug 1986 23:22:07 CDT
Subject: Re: VAX IP/TCP
From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To: Douglas M. Olson <dolson@ADA20.ISI.EDU>
cc: AFDDN.TCP-IP@GUNTER-ADAM.ARPA
In-Reply-To: (Message from "Douglas M. Olson <dolson@ADA20.ISI.EDU>" of 18 Jul 1986 13:13:22 PDT)
Doug,
The real solution to support the large number of users you talked about
would be to support TCP/IP on your ethernet and use multiple IP gateways.
PAD is a generic term for the function of turning certain data streams
into X.25 packets for transmission through a packet network, and then
turning the packets back into the data stream on the other side of the
network. The purpose is to make the network transparent to the devices
generating the data streams. The primary use for PADs is to support
synchronous terminals across packet nets. This nutshell description doesn't
cover every aspect of PADs; its just info. The bottom line is PADs are not the
solution you need.
I recently sent you a note on the uVAX configuration you were considering.
Again, the bottom line of all I said was that I don't think a uVAX can handle
the simultaneous traffic you suggest. I would probably take two to handle
60 connections and even then I think that might be pushing it since every user
will be Telneting into the uVAX and then DecNetting out to their real host in
the Cluster. FTP users will have to transfer files onto the uVAX, then get
them across the ethernet. The same will probably be true of electronic mail
using SMTP; unless there's a package for the uVAX that will forward mail
through the ethernet. If anybody out there in TCP/IP land knows of software
to make the uVAX a cleaner interface, please let me know.
I have assumed that you are running DECNET in your Cluster. I think you
should consider using TCP/IP and use gateways into the Milnet. However,
I've heard it mentioned that some folks out at JPL are working on what
has been termed a DDN/Decnet gateway. I assume such a device would translate
between the ARM protocols and Decnet and would be transparent. Again, does
anybody else have more info?
Darrel Beach
-------
-------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Sat, 16-Aug-86 14:36:37 EDT From: mm06@gte-labs.CSNET.UUCP To: mod.protocols.tcp-ip Subject: 3270 telnet option?
I have heard rumors of a 3270 emulation package intended for use as a telnet option. Does such an animal exist? If so, who wrote it? Is it available? Is there published literature describing it? The rumors I heard associated it with the UCLA IP implementation for MVS, if that is any help. This may be rather garbled, to say the least; my apologies for the lack of specifics. ---------------------------------------------- Mike Murphy GTE Laboratories, Waltham, MA mm06%gte-labs.csnet@RELAY.CS.NET ..!ihnp4!harvard!bunny!mmm06
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Aug 86 14:36:37 edt From: Michael Murphy <mm06%gte-labs.csnet@CSNET-RELAY.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: mm06@GTE-LABS.CSNET Subject: 3270 telnet option?
I have heard rumors of a 3270 emulation package intended for use as a telnet option. Does such an animal exist? If so, who wrote it? Is it available? Is there published literature describing it? The rumors I heard associated it with the UCLA IP implementation for MVS, if that is any help. This may be rather garbled, to say the least; my apologies for the lack of specifics. ---------------------------------------------- Mike Murphy GTE Laboratories, Waltham, MA mm06%gte-labs.csnet@RELAY.CS.NET ..!ihnp4!harvard!bunny!mmm06
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Sun, 17-Aug-86 18:11:44 EDT From: braden@VENERA.ISI.EDU (Bob Braden) To: mod.protocols.tcp-ip Subject: Re: 3270 telnet option?
______________________________________________________ I have heard rumors of a 3270 emulation package intended for use as a telnet option. Does such an animal exist? If so, who wrote it? Is it available? Is there published literature describing it? The rumors I heard associated it with the UCLA IP implementation for MVS, if that is any help. This may be rather garbled, to say the least; my apologies for the lack of specifics. ---------------------------------------------- Mike Murphy GTE Laboratories, Waltham, MA mm06%gte-labs.csnet@RELAY.CS.NET ..!ihnp4!harvard!bunny!mmm06 _________________________________________________________ Mike, There is an accepted mechanism for supporting full-screen IBM 3278 operation over a Telnet connection. The essential idea is that you ship the 3278 order stream transparently, after negotiating the Binary Transmission option in both directions. There is an initial Terminal Type negotiation to establish the model number, and both ends must agree that they handle End-of-Record marks (which are used to delimit keyboard and screen transactions). This mechanism is currently supported by the User and Server Telnets of both the Wisconsin VM code and the UCLA MVS code. Unforunately, there are minor differences which make the two versions almost but not quite compatible. No one has "bit the bullet" to reach a standard and document it. In addition, there are programs which run under Unix to act as the user side of the full-screen Telnet interaction, emulating a 3278 on the local ASCII CRT/workstation. The one I am familiar with is called tn3278, and was written by Greg Minshall at Berkeley. It is available by public FTP from Berkeley, although you should be aware it needs several bug fixes. I recently installed it on my Sun 3, and after I fixed the most important bugs, it provided excellent service to the UCLA 3090 running MVS (when you have to communicate through a loaded ARPANET/MILNET gateway, full- screen interaction works A LOT BETTER than character-by-character mode!!!). Bob Braden
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 86 16:01:00 PST From: <gary@acc.arpa> To: "rjwelsh" <rjwelsh@bbncc-washington> Cc: tcp-ip@sri-nic Subject: X.25 UNIBUS Interfaces
Bob, While I cannot speak directly about Simpact's offerring or their specific implementation..I can talk to you about ACC and the type of Unibus-based DDN certified X.25 interfaces we have to offer. Perhaps it would be better to present what your specific application requirement is and then attempt to find the best solution...it may also be instructive for other folks who monitor this bulletin board. Standing ready to assist through the haze.... Gary Krall ------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 86 16:09:00 PST From: <gary@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: confusion
First off, I wish to thank all the folks who responded to my inquiry concerning updating of our customer service files. It appears, however that I was not specific enough concerning the differences between HDH and LH or DH connections. By HDH I was referring to either the IF-11/HDH or IF-11Q/HDH boards which implement the 1822-J protocol. The method behind the madness is to have an accurate recording as to where they are deployed so that we may notify the appropriate point-of-contacts in the event changes are made to either the firmware or the driver software to keep them current. Thanks again for all the help... Gary Krall ------
-----------[000030][next][prev][last][first]----------------------------------------------------
Date: Mon, 18-Aug-86 17:26:29 EDT
From: rjwelsh@BBNCC-WASHINGTON.ARPA ("Robert J. Welsh")
To: mod.protocols.tcp-ip
Subject: X.25 UNIBUS cardsI am seeking information about a company and one of its products. The company is Simpact Assoc, based in San Diego, California. The product I am interested in is their UNIBUS compatible intelligent communications processor ICP1600. The card installs in UNIBUS backplanes and is based on a DEC MICRO/T-11 processor. In addition to the card, Simpact markets a software product called X.25 SVI. This implementation of X.25 supports the LAPB frame protocol and is supposed to be a DDN compliant X.25. Simpact also markets a TCP/IP that runs on their ICP1600 UNIBUS communications processor. I would appreciate hearing from anyone who has experience with Simpact Assoc and their ICP1600 intelligent communications processor, X.25 SVI and TCP/IP. I would be especially interested in hearing from anyone who is using this product line within the DDN. Other concerns include product quality, customer support, product documentation and availability. In addition, If anyone out there knows of another UNIBUS compatible card that runs a DDN compliant X.25 and supports TCP/IP (on the card), please let me know. All responses can be mailed directly to me. I will summarize and post them on the net. My E-mail address is: rjwelsh@cct.bbn.com Thanks in advance, Rob Welsh
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Aug 86 17:26:29 EDT From: "Robert J. Welsh" <rjwelsh@bbncc-washington.ARPA> To: tcp-ip@sri-nic.arpa Subject: X.25 UNIBUS cards
I am seeking information about a company and one of its products. The company is Simpact Assoc, based in San Diego, California. The product I am interested in is their UNIBUS compatible intelligent communications processor ICP1600. The card installs in UNIBUS backplanes and is based on a DEC MICRO/T-11 processor. In addition to the card, Simpact markets a software product called X.25 SVI. This implementation of X.25 supports the LAPB frame protocol and is supposed to be a DDN compliant X.25. Simpact also markets a TCP/IP that runs on their ICP1600 UNIBUS communications processor. I would appreciate hearing from anyone who has experience with Simpact Assoc and their ICP1600 intelligent communications processor, X.25 SVI and TCP/IP. I would be especially interested in hearing from anyone who is using this product line within the DDN. Other concerns include product quality, customer support, product documentation and availability. In addition, If anyone out there knows of another UNIBUS compatible card that runs a DDN compliant X.25 and supports TCP/IP (on the card), please let me know. All responses can be mailed directly to me. I will summarize and post them on the net. My E-mail address is: rjwelsh@cct.bbn.com Thanks in advance, Rob Welsh
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Mon, 18-Aug-86 20:01:00 EDT From: gary@ACC.ARPA To: mod.protocols.tcp-ip Subject: X.25 UNIBUS Interfaces
Bob, While I cannot speak directly about Simpact's offerring or their specific implementation..I can talk to you about ACC and the type of Unibus-based DDN certified X.25 interfaces we have to offer. Perhaps it would be better to present what your specific application requirement is and then attempt to find the best solution...it may also be instructive for other folks who monitor this bulletin board. Standing ready to assist through the haze.... Gary Krall ------
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Mon, 18-Aug-86 20:09:00 EDT From: gary@ACC.ARPA To: mod.protocols.tcp-ip Subject: confusion
First off, I wish to thank all the folks who responded to my inquiry concerning updating of our customer service files. It appears, however that I was not specific enough concerning the differences between HDH and LH or DH connections. By HDH I was referring to either the IF-11/HDH or IF-11Q/HDH boards which implement the 1822-J protocol. The method behind the madness is to have an accurate recording as to where they are deployed so that we may notify the appropriate point-of-contacts in the event changes are made to either the firmware or the driver software to keep them current. Thanks again for all the help... Gary Krall ------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Mon, 18-Aug-86 21:38:35 EDT From: DP4Q@TE.CC.CMU.EDU (Drew D. Perkins) To: mod.protocols.tcp-ip Subject: 64kb cards and x.25
I'm looking for a card for IBM PC's that supports syncronous/sdlc/hdlc communications up to 64kb. What I have in mind should hopefully have a Zilog SCC (8530) chip, interrupt capability, and fullduplex transmit and receive DMA capability. An onboard processor would be nice but not required. The intended application is running TCP/IP over the line. I'm currently using the Tangent Technologies PC MacBridge card which satisfies all requirements but the transmit dma capability. If anyone knows of another card, PLEASE let me know, I'm getting desperate! Also, If anyone knows of any public domain X.25 LAPB code, I'd also like to hear about it. Preferably written in C. I'd like to provide flow control and error recovery on the 64kb link without reinventing the wheel. Thanks, Drew drew.perkins@te.cc.cmu.edu -------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 86 22:04 PDT From: Jeff Makey <Makey@LOGICON.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: Makey@LOGICON.ARPA Subject: Time-to-live boundary conditions
If a gateway receives an IP segment whose time-to-live field has a
value of 1 (one), should it transmit the segment after decrementing the
TTL field to 0? RFC 791 (Internet Protocol) is not clear on this.
:: Jeff Makey
Makey@LOGICON.ARPA
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Wed, 20-Aug-86 01:04:00 EDT From: Makey@LOGICON.ARPA (Jeff Makey) To: mod.protocols.tcp-ip Subject: Time-to-live boundary conditions
If a gateway receives an IP segment whose time-to-live field has a
value of 1 (one), should it transmit the segment after decrementing the
TTL field to 0? RFC 791 (Internet Protocol) is not clear on this.
:: Jeff Makey
Makey@LOGICON.ARPA
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Wed, 20-Aug-86 14:24:08 EDT From: gmiller@CC6.BBN.COM To: mod.protocols.tcp-ip Subject: Re: Time-to-live boundary conditions
Jeff, I am the tester for a BBNCC product called a Mailbridge. Mailbridges are a type of gateway. The way we have interpreted the TTL lower boundary condition is that 1 is the lower limit for the receiving device. For the case you stated, a datagram to be transmitted through a Mailbridge, 2 is the lowest limit for an incoming datagram. The datagram will be transmitted with TTL decremented to 1. Gerry Miller gmiller@CC6.BBN.COM
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 86 2100 PDT From: Joe Weening <JJW@SAIL.STANFORD.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: Telnet binary mode
I'd like to find out what reasons people have for using Telnet binary
mode. Do you use it for any of the following?
a. To allow setting the 8th bit along with an ASCII character;
b. To avoid the NVT CR/LF conventions;
c. Some other pre-arranged interpretation between the hosts. If so,
how is this interpretation agreed on?
I've recently discovered that reason (a) is often unnecessary because many
systems allow the 8th bit without complaint. (Is this a bug or a
feature?) It seems easier to not use binary mode, and put up with the NVT
CR/LF conventions, to avoid a disagreement between the two sides about the
meaning of binary mode.
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Aug 86 21:48 PDT From: Provan@LLL-MFE.ARPA To: tcp-ip@sri-nic.arpa Subject: the length of 802.3 + 802.2 header
this isn't quite the right mailing list for this, but i'm sure i'll get a correct answer from someone reading this... i've gone over it a hundred times, and i swear the length of the header on an 802.2 type 1 packet is 17 bytes: 14 bytes for the 802.3 (aka "ethernet") header and 3 bytes for the 802.2 header. that is, the data will begin at byte number 18 (if the first byte is "1") of the transmitted packet. maybe it's my ARPAnet training, but a header with an odd number of bytes is so incredible that i just can't believe it. could someone please confirm that this is, in fact, correct, or, even better, point out where i'm making my mistake and show me why it's really an even number? i'd appreciate it. don
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 21-Aug-86 00:00:00 EDT From: JJW@SAIL.STANFORD.EDU (Joe Weening) To: mod.protocols.tcp-ip Subject: Telnet binary mode
I'd like to find out what reasons people have for using Telnet binary
mode. Do you use it for any of the following?
a. To allow setting the 8th bit along with an ASCII character;
b. To avoid the NVT CR/LF conventions;
c. Some other pre-arranged interpretation between the hosts. If so,
how is this interpretation agreed on?
I've recently discovered that reason (a) is often unnecessary because many
systems allow the 8th bit without complaint. (Is this a bug or a
feature?) It seems easier to not use binary mode, and put up with the NVT
CR/LF conventions, to avoid a disagreement between the two sides about the
meaning of binary mode.
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Thu, 21-Aug-86 00:48:00 EDT From: Provan@LLL-MFE.ARPA To: mod.protocols.tcp-ip Subject: the length of 802.3 + 802.2 header
this isn't quite the right mailing list for this, but i'm sure i'll get a correct answer from someone reading this... i've gone over it a hundred times, and i swear the length of the header on an 802.2 type 1 packet is 17 bytes: 14 bytes for the 802.3 (aka "ethernet") header and 3 bytes for the 802.2 header. that is, the data will begin at byte number 18 (if the first byte is "1") of the transmitted packet. maybe it's my ARPAnet training, but a header with an odd number of bytes is so incredible that i just can't believe it. could someone please confirm that this is, in fact, correct, or, even better, point out where i'm making my mistake and show me why it's really an even number? i'd appreciate it. don
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Thu, 21-Aug-86 13:24:56 EDT From: ron@BRL.ARPA (Ron Natalie) To: mod.protocols.tcp-ip Subject: Re: Time-to-live boundary conditions
Likewise, the BRL gateways will discard incoming datagrams with packet counts of zero or one. Hence, any datagram that comes in with a TTL of Zero will be discarded and datagrams to be forwarded that have a time to live of zero after they've been decremented are discarded as well. The SPEC says that the packet will be discarded when the time to live is detected as being zero. We interpret that to mean at any time prior to transmission. -Ron
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Thu, 21-Aug-86 18:36:17 EDT From: OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen) To: mod.protocols.tcp-ip Subject: New Vendors Guide
The NIC is proud to announce the availability of the August 1986 edition of THE DDN PROTOCOL IMPLEMENTATIONS AND VENDORS GUIDE (formerly the TCP/IP Implementations and Vendors Guide). In addition to including X.25 products as well as TCP/IP implementations, the new document also has a section with background information about the DDN, protocol policy, testing and evaluation, and document ordering information. To order the document, send check, money order or purchase order for $20.00 ($23.00 foreign) payable to "SRI International". Our address is: DDN Network Information Center SRI International, Room EJ291 333 Ravenswood Avenue Menlo Park California 94025 USA You may also use FTP to retrieve the file (which is updated on a continuous basis) from SRI-NIC.ARPA using the pathname: NETINFO:VENDORS-GUIDE.DOC We welcome additions/corrections. If you have a relevant product or package which is not listed , please let us know. Ole J Jacobsen DDN Network Information Center -------
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Fri, 22-Aug-86 10:05:03 EDT From: jmoy@BRUBECK.PROTEON.COM To: mod.protocols.tcp-ip Subject: re: length of 802.3 + 802.2 header
Don- I think that your calculation is correct. I recently wrote a driver for IP on an 802.5 network and encountered the same problem. My first reaction was that I must be crazy. Seems that this is going to cause problems for alot of people's architectures. John Moy Proteon -------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Fri, 22-Aug-86 11:37:51 EDT From: bjp@MITRE-BEDFORD.ARPA To: mod.protocols.tcp-ip Subject: Possible DDN to Ethernet or 802.3 Gateway Vendors
Thanks to all who responded to my requent for information on vendors who sell DDN X.25 Standard to 802.3 or Ethernet gateways. Since many folks requested me to pass along the information I recieved, I have summarized it below with some of the origional comments about each product and vendor. Two other possible sources of information are: NETINFO:TCP-IP-IMPLEMENTATIONS.TXT, NETINFO:VENDORS-GUIDE.DOC. These were also recommended. bj Pease 1. Communications Machinery Corporation (CMC) 1421 State Street Santa Barbara, CA 93101 (805) 963-9471 DDN Ethernet Gateway, X.25 interface to DDN, and either type 1 or 802.3. Model # DRN-3200. 2. Proteon does have a DDN X.25 gateway product. JNC@PROTEON.COM 3. Scope Inc. 800-336-0155 (Carl Kelley). 4. ARINC Research 301-266-4787. (Wally Miller). 5. Communication Interface Solutions Company (CISCO), Gaithersburg, MD. One respondent highly recommended this company. (301) 921-8800 or 800-638-8296 (Jon Weston) (415) 723-0045 (Len Bosack). 6. Auscom 512-836-8080 (Iraj Vojdam). 7. BBN - Butterfly Gateway (may not support DDN X.25 Standard). BLUMENTHAL@BBN-UNIX.ARPA. 8. Avanced Computer Communications, Inc (ACC). Santa Barbara, CA Gary Krall (805) 963-9431 GARY@ACC.ARPA 9. Sun Microsystems Inc. They have DDN X.25 basic and are working on DDN X.25 Standard. They now have a HDH DDN interface with same hardware as X.25 (synchronous MIL-188, RS422). 10. Bridge Communications.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Fri, 22-Aug-86 13:48:39 EDT From: jas@BRUBECK.PROTEON.COM To: mod.protocols.tcp-ip Subject: Re: the length of 802.3 + 802.2 header
Your measurements of the length of a LLC Class 1 header are completely correct. It is 3 bytes long! This is all in the spirit of the ISO OSI protocol families. No attempt is made in any of the protocols to preserve 'nice' alignment of fields longer than one byte. Perhaps they consider density more important than performance. Remember that on X.25 in Europe you often pay by the byte. The Connectionless Internet protocol has a very small fixed-format header, which does not even contain the destination address. Since the destination address is variable-length, it is the variable part of the header. In general, the first code any ISO OSI implementor has to write is the stuff that serially parses the headers. Most of the variable length fields are of the format: byte type byte length var data[] You parse them serially, from beginning to end. Given this mindset, the 802.2 people probably saw no reason to have an even length header, as things would get odd soon enough. Also, why waste a byte. As for those of us who designed protocols for efficiency, we're out of luck. One strategy is to receive 802.2-grams on an odd boundary, so that the LLC1/IP pairing will wind up well aligned. Other protocols don't care, so this wins. (Just for more fun, when you use the SNAP protocol for extending the protocol ID [ie. SAP], the header becomes even length again. Aauugh!) john shriver proteon p.s. I suspect the whole 802.2 mess will be one of the active discussion topics at the Implementor's Workshop... -------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Aug 86 06:45:00 EDT From: jqj@gvax.cs.cornell.edu (J Q Johnson) To: arpa.tcp-ip Subject: Re: the length of 802.3 + 802.2 header
I don't completely see why the fuss over odd sized headers. Presumably, the encapsulation of the contained protocol is a separate standardization issue from the header formats. Just as 4.2bsd chose a nonobvious encapsulation for ip on Ethernet (trailers), we could legislate that ip under 802.2 is required to include an adequate number of pad bytes to force word (or whatever) alignment. I don't care much if OSI IP is slow -- I plan to continue to run tcp/ip at least until it becomes feasible to put a barrel shifter in my Ethernet interfaces! However, I will need to use 802.2 and saps as transports...
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Sun, 24-Aug-86 09:03:52 EDT From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) To: mod.protocols.tcp-ip Subject: Re: Telnet binary mode
Joe -
A purist would argue that NVT ASCII is 7 bits unless binary mode has
been negotiated. The Telnet specification is vague on this point, but it
does refer to the "128 possible characters in NVT ASCII" in a few places.
I believe that 8 bit transmission in non-binary mode is a bug, since it
interferes with local parity handling.
The parity issue is important, although many implementors (myself
included, alas) have never bothered to implement parity correctly.
I know that vanilla DEC TOPS-20 does not enforce 7-bit NVT ASCII on
input to an NVT. It also doesn't enforce IAC doublings on output from an
NVT. I consider both of these to be bugs, in spite of the fact that
certain individuals have written programs to exploit them. The PANDA
versions of TOPS-20 (SIMTEL20, STL-HOST1, DREA-XX) all have these bugs
fixed, as do several other sites.
Significantly, the TAC also enforces 7-bit ASCII in non-binary mode.
I think that it is prudent to negotiate binary mode on any Telnet
connection in which you wish to transmit 8-bit ASCII. The only hosts I
know of which have problems with binary mode are certain broken versions
of Unix. As far as I can tell mainstream Unix handles binary mode
reasonably.
-- Mark --
-------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 24 Aug 1986 11:55-EDT From: CERF@A.ISI.EDU To: MRC%PANDA@SUMEX-AIM.ARPA Cc: JJW@SU-AI.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Telnet binary mode
Mark, please refresh my memory - how do the Unix systems get backout of binary mode once in it? Vint
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Sun, 24-Aug-86 15:49:27 EDT From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) To: mod.protocols.tcp-ip Subject: Re: Telnet binary mode
Vint -
I don't know the answer to your question. Most hosts don't offer
a way out, but PANDA TOPS-20 systems have a TERMINAL NETWORK-BINARY command
with an optional argument of BOTH, INPUT, or OUTPUT (the default is BOTH)
to get into network binary from the host (in addition to client means such
as TAC @ B I S and @ B O S) and a corresponding TERMINAL NO NETWORK-BINARY
to get out.
I think that all hosts should have such a facility if 8 bit I/O is at
all meaningful on NVT's.
-- Mark --
-------
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Aug 86 10:45:51 EDT From: lzaz!jmc@seismo.CSS.GOV To: mod.protocols.tcp-ip,mod.protocols tcp-ip@sri-nic.arpa Subject: X.25 Negotiation
There is some disagreement, at our particular site, over what OSI layer is responsible for packet size negotiation. It is of particular interest to us especially since this can affect performance as far as the PAD is concerned and increasing overhead by increasing the size and complexity of the transport PAD protocol layer. The CCITT X.25 standard 1984 seems to indicate that it is the Network layers responsibility since it is the most actively aware of the link packet size, link speed and does the packet assembly and disassembly. Any thoughts or reference articles would be useful Thanks. Jan M. Clairmont
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Mon, 25-Aug-86 15:46:37 EDT From: ron@BRL.ARPA (Ron Natalie) To: mod.protocols.tcp-ip Subject: VMS TCP/IP
I have been trying to help our VMS people get their TCP/IP working. What we are using is the DTI->COMPION->GOULD->INTERNET VMS code now called Hyperlink. I spoke with someone who claimed to be the person working on the code and they seem to be a little naive about how IP works. The problem is to set up the routing table it is required to make entries for every gateway in the internet. They have a program that generates this from a NIC host table, but here lies the problem. There is no concept of DEFAULT route, nor is EGP used so there is no way to make this system work reliably in todays Internet. Consider the following network. VMS HOST <--NET A--> GATEWAY <--NET B--> GATEWAY <--NET C--> TARGET addr A.v A.g B.g B.h C.h C.t There is a VMS machine on net A with address A.v, a gateway between nets A and B with interface address A.g and B.g respectively, etc... To get the Hyperlink code to route to the TARGET, you need the following enties in their table Interet Address Gateway A.g B.g B.g A.g B.h C.h C.h B.h Note there are four entries here (don't ask me why it needs them in both directions). The problem comes in that gateways must be up to date in the nic-table. Note that this neither provides for the dynamics provided by EGP, nor does it help people who are not on MILNET but on little stubs that the entire world is on the far side of a single gateway (such as the VMS machine at BRL). When I mentioned this to them, they said no one had ever complained before, and that the X.25 validated system solved the problem with the name daemon (right). I don't believe that either. Anyway, since they seem to be ignorant of the problem, I guess I'm going to half to kludge up a table that lists every NET number in the net and fake it pointing at the DEFAULT gateway and vice versa. It turns my stomach. It's really amazing what you can get away with in a DDN-validated system. Just what are they validating? By the way, we can't use Woolengong since the refuse to provide any way for us to handle IMPs on Class B internet number networks (like either doing it for us, or providing some way to get the source). And as far as VMS is concerned, I think it is a shame to leave a VAX running diagnostics all day. -Ron
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Aug 86 15:46:37 EDT From: Ron Natalie <ron@BRL.ARPA> To: tcp-ip@sri-nic.arpa Subject: VMS TCP/IP
I have been trying to help our VMS people get their TCP/IP working. What we are using is the DTI->COMPION->GOULD->INTERNET VMS code now called Hyperlink. I spoke with someone who claimed to be the person working on the code and they seem to be a little naive about how IP works. The problem is to set up the routing table it is required to make entries for every gateway in the internet. They have a program that generates this from a NIC host table, but here lies the problem. There is no concept of DEFAULT route, nor is EGP used so there is no way to make this system work reliably in todays Internet. Consider the following network. VMS HOST <--NET A--> GATEWAY <--NET B--> GATEWAY <--NET C--> TARGET addr A.v A.g B.g B.h C.h C.t There is a VMS machine on net A with address A.v, a gateway between nets A and B with interface address A.g and B.g respectively, etc... To get the Hyperlink code to route to the TARGET, you need the following enties in their table Interet Address Gateway A.g B.g B.g A.g B.h C.h C.h B.h Note there are four entries here (don't ask me why it needs them in both directions). The problem comes in that gateways must be up to date in the nic-table. Note that this neither provides for the dynamics provided by EGP, nor does it help people who are not on MILNET but on little stubs that the entire world is on the far side of a single gateway (such as the VMS machine at BRL). When I mentioned this to them, they said no one had ever complained before, and that the X.25 validated system solved the problem with the name daemon (right). I don't believe that either. Anyway, since they seem to be ignorant of the problem, I guess I'm going to half to kludge up a table that lists every NET number in the net and fake it pointing at the DEFAULT gateway and vice versa. It turns my stomach. It's really amazing what you can get away with in a DDN-validated system. Just what are they validating? By the way, we can't use Woolengong since the refuse to provide any way for us to handle IMPs on Class B internet number networks (like either doing it for us, or providing some way to get the source). And as far as VMS is concerned, I think it is a shame to leave a VAX running diagnostics all day. -Ron
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Wed, 27-Aug-86 18:12:21 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: Re: X.25 Negotiation
Jan Officially, it is possible to negotiate for non-standard default size in the Call Request Packet (see section on Procedure and Formats for optional user facilities). In practice, most administration will limit you to either 128 or 256 bytes in order to achieve better resource ultilisation of the packet switching node. This effectively makes size negotiation pretty mieaningless. Of course if you are running TP-4 on top of X25, you can do TPDU size negotiation. If your TPDU size is greater than the NPDU size, then you have to do network level fragmentation and set M-bit in your X25 packet accordingly. John Leong
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 28-Aug-86 18:15:11 EDT From: michael@VLSI.CALTECH.EDU To: mod.protocols.tcp-ip Subject: LH/DH-11
Yes, I know this isn't terribly appropriate for this group, but... Does anybody have a working LH/DH-11 that they'd like to sell? Thanx. Michael Lichter Caltech Computer Science michael@vlsi.caltech.edu
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Fri, 29-Aug-86 13:53:42 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: Request for info : 3B20, Bitnet
Request for information : (a) Does any one know of any UNIX 4.2 or 4.3 package for a 3B20-400 ? If not, what about TCP/IP for UNIX System V for that machine ? (b) Can anyone tell me if there is a package that will allow a UNIX 4.2 or 4.3 system to connect to Bitnet and where can one obatin such a package ? Thanks in advance for your assistance. John Leong leong@andrew.cmu.edu
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Fri, 29-Aug-86 14:20:45 EDT From: nhall@CRYS.WISC.EDU (Nancy Hall) To: mod.protocols.tcp-ip Subject: Re: 64kb cards and x.25
Drew - Since there seems to be a fair amt of interest in this, I'm posting to the net instead of sending directly to you. I've been looking for full X.25 plp on a card for the AT but (actually for a PC/RT, so things that rely on software running w/ DOS won't do). Here's a brief list of some companies that offer some sort of hardware, many of which I've rejected because of my somewhat restrictive needs (e.g., they offer LAPB on the card but not PLP), but which may be useful to you. Frontier Technologies P.O. Box 11238 Milwaukee, Wisconsin 53211 (414) 964-8689 TCP/IP, X.25, HDLC on the card, w/ interfaces to all levels. Eicon Technology Corp. 3452 Ashby St. Montreal, Quebec H4R 2C1 (514) 333-8543 Based on the Netbios interface. As far as I can tell has HDLC only on the board. Scope, Inc. 1860 Michael Faraday Drive Reston, Virginia 22090 (703) 471-5600 Their DDN Microgateway has HDLC, LAPB, 1822 HDH, X.25 (presumably plp) and TCP/IP on the board. Also have a multibus version. Trisystems 74 Northeastern Blvd. Unit 22 Nashua, NH 03062 (603) 883-0558 HDLC/ LAPB on the board as I recall - better check w/ them on this. ADAX Corp. Berkeley (415) 543-7047 Primitive board X.25/HDLC, TCP/IP, SNA/SDLC in software w/ host overhead. LYNBAR Datacom Products Fort Worth, TX (817) 431-3460 Several products, HDLC, assumes DOS i think. No info about these next few companies; I just received these addresses from other sources but haven't checked them out yet: INS Corp. Mobile, Alabama (205) 633-3270 ABM Computer Systems 3 Whatney Irvine, CA 92714 S-Com Computer System Engineers, Ltd. Tower House High Street Aylesbury, Bucks. HP20 1SQ UK IBM also supposedly has a product announced in Paris but not in the US (?) and I'm trying to find out about it but haven't learned anything yet. I hope this is of some help. - Nancy
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Fri, 29 Aug 86 14:28:27 EDT From: Jeffrey C Honig <$JCH%CLVM.BitNet@ucbvax.Berkeley.EDU> To: Info-Vax Mailing List <Info-VAX@sri-kl.arpa>, tcp-ip@sri-nic.arpa Subject: Ethernet between buildings
One of our departments is installing some diskless Sun workstations in two buildings with a Sun file server in another. This of course necessitates the use of Ethernet between the buildings (which are right next to each other). Up here in Northern NY we get alot of thunderstorms during the summer and fall (especially this year!) and are worried about lightning damage. We asked Sun for Ethernet configurations guidelines and were sent a copy of DEC's "Ethernet Installation Guide". This manual recommends that Fiber be used between buildings because it "Eliminates any potential interbuilding grounding problems". We know there are no grounding problems. DEC does does give information about running baseband between buildings but does not even mention lightning arrestors. The department doesn't want to spent the 10k to use fiber but I don't want to recommend that they use baseband until I see some written documentation on lightning protection. Does anyone have any experience in this area or can anyone recommend some specifications that deal with the subject? Thanks much Jeffrey C Honig Schuler Educational Resources Center Clarkson University Potsdam, NY
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 29 Aug 1986 19:27:12 PDT From: POSTEL@B.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: How to IP & ARP on 802 Nets
Hello.
At an ad hoc special session on "IEEE 802 Networks and ARP" held
during the recent TCP Vendors Workshop, an approach to a consistent
way to sent DOD-IP datagrams and other IP related protocols on 802
networks was developed.
Due to some evolution of the IEEE 802.2 standards and the need to
provide for a standard way to do additional DOD-IP related protocols
(such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the
following new policy is being proposed, which will replace the current
policy (see page 26 of RFC-960 and RFC-948).
The proposal is for DDN and ARPA-Internet community to use IEEE
802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the
SNAP with an organization code indicating that the following 16 bits
specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of
RFC-960).
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC Header
...--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP Header
+--------+--------+--------+
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP Header
+--------+--------+---------+--------+--------+
The values of K1 and K2 must be assigned by the IEEE. We believe
there is already assigned a value of K1 that indicates that the
5-octet SNAP header follows. We can use this value. There may be a
value of K2 that is already assigned that indicates that the last two
octets of the SNAP header holds the EtherType. If so we may be able
to use this value. This remains to be explored. The EtherTypes are
assigned by Xerox (as always).
The total length of the SAP Header and the SNAP header is 8-octets,
making the 802.2 protocol overhead come out on a nice octet boundary.
If we can not quickly resolve the issue of the values for K1 and K2,
we will push for the assignment of a sap value (a K1 value) to
indicate "IP related protocols" and do our own multiplexing (much like
that proposed above).
In any case, we will not create incompatible interpretations of
headers already in use on 802 networks.
--jon.
-------
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Fri, 29-Aug-86 22:04:01 EDT From: GKN@SDSC.BITNET (Gerard K. Newman) To: mod.protocols.tcp-ip Subject: packet sizes
From: lzaz!jmc@seismo.CSS.GOV
Subject: X.25 Negotiation
Date: Mon, 25 Aug 86 10:45:51 EDT
There is some disagreement, at our particular site, over what OSI
layer is responsible for packet size negotiation.
The transport layer is the first layer which is responsible for determining
frame size, and provides segmenting and blocking to meet the restrictions
imposed by station/network management.
The network layer also provides blocking and segmenting to meet network
frame size requirements. Generally the link layer does not do blocking
or segmentation. So, typically the network layer provides "efficient"
frame sizes to the link layer. If the link layer has adjustable frame
sizes the network layer and station/network management would be responsible
for them.
X.25 can be considered both as a network and a transport level service.
In the context of most full-service networks X.25 provides only link
level services, hiding intermediate X.25 nodes from the larger network's
routing tables.
In lieu of a "strong" station/network management layer the network layer
would be responsible for selecting the link layer frame size.
gkn
---------------------------------------
Arpa: GKN%SDSC.BITNET@WISCVM.WISC.EDU
USPS: Gerard K. Newman
San Diego Supercomputer Center
P.O. Box 85608
San Diego, CA 92138
AT&T: 619.534.5076
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Fri, 29-Aug-86 22:27:12 EDT From: POSTEL@B.ISI.EDU To: mod.protocols.tcp-ip Subject: How to IP & ARP on 802 Nets
Hello.
At an ad hoc special session on "IEEE 802 Networks and ARP" held
during the recent TCP Vendors Workshop, an approach to a consistent
way to sent DOD-IP datagrams and other IP related protocols on 802
networks was developed.
Due to some evolution of the IEEE 802.2 standards and the need to
provide for a standard way to do additional DOD-IP related protocols
(such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the
following new policy is being proposed, which will replace the current
policy (see page 26 of RFC-960 and RFC-948).
The proposal is for DDN and ARPA-Internet community to use IEEE
802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the
SNAP with an organization code indicating that the following 16 bits
specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of
RFC-960).
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC Header
...--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP Header
+--------+--------+--------+
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP Header
+--------+--------+---------+--------+--------+
The values of K1 and K2 must be assigned by the IEEE. We believe
there is already assigned a value of K1 that indicates that the
5-octet SNAP header follows. We can use this value. There may be a
value of K2 that is already assigned that indicates that the last two
octets of the SNAP header holds the EtherType. If so we may be able
to use this value. This remains to be explored. The EtherTypes are
assigned by Xerox (as always).
The total length of the SAP Header and the SNAP header is 8-octets,
making the 802.2 protocol overhead come out on a nice octet boundary.
If we can not quickly resolve the issue of the values for K1 and K2,
we will push for the assignment of a sap value (a K1 value) to
indicate "IP related protocols" and do our own multiplexing (much like
that proposed above).
In any case, we will not create incompatible interpretations of
headers already in use on 802 networks.
--jon.
-------
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Fri, 29 AUG 1986 22:17 GMT From: Gerard K. Newman <GKN%SDSC.Bitnet@WISCVM.WISC.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: packet sizes
From: lzaz!jmc@seismo.CSS.GOV
Subject: X.25 Negotiation
Date: Mon, 25 Aug 86 10:45:51 EDT
There is some disagreement, at our particular site, over what OSI
layer is responsible for packet size negotiation.
The transport layer is the first layer which is responsible for determining
frame size, and provides segmenting and blocking to meet the restrictions
imposed by station/network management.
The network layer also provides blocking and segmenting to meet network
frame size requirements. Generally the link layer does not do blocking
or segmentation. So, typically the network layer provides "efficient"
frame sizes to the link layer. If the link layer has adjustable frame
sizes the network layer and station/network management would be responsible
for them.
X.25 can be considered both as a network and a transport level service.
In the context of most full-service networks X.25 provides only link
level services, hiding intermediate X.25 nodes from the larger network's
routing tables.
In lieu of a "strong" station/network management layer the network layer
would be responsible for selecting the link layer frame size.
gkn
---------------------------------------
Arpa: GKN%SDSC.BITNET@WISCVM.WISC.EDU
USPS: Gerard K. Newman
San Diego Supercomputer Center
P.O. Box 85608
San Diego, CA 92138
AT&T: 619.534.5076
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Sun, 31 Aug 86 18:56:51 CDT From: Phil Howard <PHIL%UIUCVMD.BITNET@WISCVM.WISC.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: Grounding Ethernet
Grounding may be fine at most times; during thunderstorms, there tends to be a peculiar electrical ground flow that follows thunderstorms. This flow is opposite polarity to lower cloud bases, and tends to be the driving force behind lightning. Good grounding could actually bring about more lightning strikes. If you at all can, go with fiber.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Sun, 31-Aug-86 19:56:51 EDT From: PHIL@UIUCVMD.BITNET (Phil Howard) To: mod.protocols.tcp-ip Subject: Grounding Ethernet
Grounding may be fine at most times; during thunderstorms, there tends to be a peculiar electrical ground flow that follows thunderstorms. This flow is opposite polarity to lower cloud bases, and tends to be the driving force behind lightning. Good grounding could actually bring about more lightning strikes. If you at all can, go with fiber.
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |