The 'Security Digest' Archives (TM)

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

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 Subnets


maybe 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 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

-----------[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