The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for February 1987 (202 messages, 99033 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Feb-87 10:42:00 EST
From:      HANK@BARILVM.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Looking for Tcp/Ip for Prime's PRIMOS system

I have seen that Prime has a Tcp/Ip version.  I am interested in hearing
any user experience with this package - costs, benefits, pros, cons, etc.
 
Please reply directly to me since I am not on this list.
 
Thanks,
Hank

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Feb-87 12:54:06 EST
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: de-multiplexing (was Gateway Monitoring)

Mike,

I wanted to respond to your comments about user process use of protocols
unimplemented by the kernel (Bill of Rights, Article 10).  4.3BSD UNIX
does allow user processes access to such protocols by the use of "raw"
sockets in the INET protocol family.  No support for demultiplexing is
provided; multiple listeners on the same protocol receive copies of
all packets.  This facility was not present in 4.2BSD.

		Mike

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1987 at 1410-EST
From:      hsw at TYCHO.ARPA  (Howard Weiss)
To:        tcp-ip at sri-nic
Cc:        jim, franceus, lee, jackson, loscocco, huckaby
Subject:   Weird Gateway Re-directs!

Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126)
received this morning.  The packets were being sent to BBNCC-COLUMBIA.ARPA
(8.1.0.35) and were being sent thru the BBNNET2-ARPANET-GW (10.7.0.63,
8.3.0.9).  The following round-the-world tour is the result.  Do any of
the gateway gurus have any words of wisdom on this?  It seems awfully
strange from where I sit!  Why the hops to the MILNET and why the loops
in the West Coast gateways?

Howard Weiss

---------------------------------------

ICMPIn: type = 5, code = 0 from 10.7.0.63  /* BBNNET2-ARPANET-GW            */
ICMPIn: Redirect to 10.5.0.5               /* redirecting to BBN-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.49) on the milnet     */

ICMPIn: type = 5, code = 0 from 10.5.0.5   /* BBN-MILNET-GW                 */
ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET     */

ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET    */

ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
ICMPIn: Redirect to 10.4.0.51              /* redirecting to SRI-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.73) on the MILNET     */

ICMPIn: type = 5, code = 0 from 10.4.0.51  /* SRI-MILNET-GW                 */
ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET     */

ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET    */

ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
ICMPIn: Redirect to 10.4.0.82              /* redirecting to BBN-ENET-2-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (8.3.0.8) on the BBN-NET-TEMP */

/* Wow - finally got there !!   */
-------

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Feb-87 14:15:33 EST
From:      shapiro@oucs.ohiou.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: oucs!shapiro
From: shapiro@oucs.OHIOU.EDU (Brian Shapiro)
Newsgroups: mod.protocols.tcp-ip
Subject: Help: tcp-ip vs. xns
Message-ID: <472@oucs.OHIOU.EDU>
Date: 2 Feb 87 19:15:31 GMT
Distribution: mod
Organization: Ohio University CS Department, Athens
Lines: 19

There has been consideration given to the idea of converting our Bridge
communications XNS based network over to TCP-IP protocol. This is being 
considered because a statewide supercomputer center is in the works. We
are not a DoD research site have no access to ARPAnet without going thru
the BITNET-ARPA net gateways. Is ther anyone out there that can tell me
what advantages we will have using TCP-IP vs. XNS? I also know very little
about TCP-IP and would like to know more. Can anyone send me a brief 
comparison between the two. Oh, I almost forgot what are the disadvantages
of TCP-IP vs. XNS.
 
Any help that can be given would be gratefully appreciated.....
 
Brian Shapiro
Ohio University Computing and Learning Services
Haning Hall
Athens, Ohio  45701
 
(614) 593-1608

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Feb-87 14:43:17 EST
From:      hsw@TYCHO.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Weird Gateway Re-directs!


Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126)
received this morning.  The packets were being sent to BBNCC-COLUMBIA.ARPA
(8.1.0.35) and were being sent thru the BBNNET2-ARPANET-GW (10.7.0.63,
8.3.0.9).  The following round-the-world tour is the result.  Do any of
the gateway gurus have any words of wisdom on this?  It seems awfully
strange from where I sit!  Why the hops to the MILNET and why the loops
in the West Coast gateways?

Howard Weiss

---------------------------------------

ICMPIn: type = 5, code = 0 from 10.7.0.63  /* BBNNET2-ARPANET-GW            */
ICMPIn: Redirect to 10.5.0.5               /* redirecting to BBN-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.49) on the milnet     */

ICMPIn: type = 5, code = 0 from 10.5.0.5   /* BBN-MILNET-GW                 */
ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET     */

ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET    */

ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
ICMPIn: Redirect to 10.4.0.51              /* redirecting to SRI-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.73) on the MILNET     */

ICMPIn: type = 5, code = 0 from 10.4.0.51  /* SRI-MILNET-GW                 */
ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET     */

ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET    */

ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
ICMPIn: Redirect to 10.4.0.82              /* redirecting to BBN-ENET-2-GW  */
ICMPIn: Message original dest was 8.1.0.35 /* (8.3.0.8) on the BBN-NET-TEMP */

/* Wow - finally got there !!   */
-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Feb-87 22:27:45 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Submission for mod-protocols-tcp-ip

Brian,  In a nutshell:  TCP/IP and XNS are very similar in the kinds of
low level services they offer (like connecting terminals to hosts).
In the higher level services (like file transfer and email) they differ
only in the aspect of how many different host types does your situation
need to communicate with.  TCP/IP has implementations
on essentially every host in existence.  XNS is much more limited
in that respect.  In your situation going with TCP/IP can only
open up your choices.  Bridge is offering you equivalent initial
functionality with a "bridge" to further functionality (by moving
to TCP/IP).  You say that you will be connecting to a supercomputer
center soon.  It will undoubtedly be TCP/IP based.  And gaining access
to BITNET (meanwhile) is very close to working in TCP/IP land
as their mail protocols are very close to TCP/IP's and getting
closer.  I'll send you some more materials in the US Snail, includi9ng
a reading list.

Dan
-------

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 1987 22:27:45 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Submission for mod-protocols-tcp-ip
Brian,  In a nutshell:  TCP/IP and XNS are very similar in the kinds of
low level services they offer (like connecting terminals to hosts).
In the higher level services (like file transfer and email) they differ
only in the aspect of how many different host types does your situation
need to communicate with.  TCP/IP has implementations
on essentially every host in existence.  XNS is much more limited
in that respect.  In your situation going with TCP/IP can only
open up your choices.  Bridge is offering you equivalent initial
functionality with a "bridge" to further functionality (by moving
to TCP/IP).  You say that you will be connecting to a supercomputer
center soon.  It will undoubtedly be TCP/IP based.  And gaining access
to BITNET (meanwhile) is very close to working in TCP/IP land
as their mail protocols are very close to TCP/IP's and getting
closer.  I'll send you some more materials in the US Snail, includi9ng
a reading list.

Dan
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 02 Feb 87 17:42:00 O
From:      Henry Nussbacher <HANK@BARILVM>
To:        tcp-ip@sri-nic.ARPA
Subject:   Looking for Tcp/Ip for Prime's PRIMOS system
I have seen that Prime has a Tcp/Ip version.  I am interested in hearing
any user experience with this package - costs, benefits, pros, cons, etc.
 
Please reply directly to me since I am not on this list.
 
Thanks,
Hank
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 87 14:39 PST
From:      Tom Perrine <Perrine@LOGICON.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        Tom Perrine <Perrine@LOGICON.ARPA>
Subject:   PSN physical locations?
Is there any way I can find out where the ARPA or MILNET PSN are
located?  (A file a SRI-NIC, maybe?) I am specifically interested in
the San Diego area.  I know about NOSC, are there any others?

Tom Perrine

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Feb-87 14:23:43 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Weird Gateway Re-directs!

Howard, you seem to have captured a routing transient.

For about the past week, and through about 3pm EST Monday afternoon, there was
a growing problem with congestion on the arpanet.  Because of this congestion,
the gateways (core, butterfly, and egp) were losing track of their neighbor
connections, and making a lot of changes to the routing information they
maintain.  Between about 9am and noon EST, I had brought down various gateways
which had been providing redundant routes to satnet, wideband, and bbnnet.
Specifically, I had disconnected 8.3.0.9 (bbn2), 10.3.0.82 (bbn), 10.4.0.82
(bbn-e2), sri-wb (10.3.0.51), and css (10.2.0.25).  This was an attempt to
provide single path routes, and reduce the gateway routing overhead.  The
arpanet programmers will probably have some specific recommendations coming
out soon, because the current respite seems shaky.

For the gateways, we are designing methods to make the neighbor connections
more robust in the face of long delays, wildly varying delays, and long
internal queues.  We aim to reduce the apparent instability in the internet
when the arpanet gets congested.

--

     Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126)

This specific set of redirects would be even more interesting if we knew when
they happened.  I suspect it was around the time when I brought down the first
interface at 8.3.0.9 (other side of 10.7.0.63), around 9am EST.  Please don't
be mislead by the redirects to various other gateways; this does not mean the
packets went to the sri-ethernet, or milnet.  They went in and out the same
arpanet interface of each gateway which issued a redirect.

Additional information I could use would be how often and how long the
redirect flurry was going on.  It does seem that the route settled after only
a 'short' time.  This means that it is useful if your host retains network
route information over a longer time than the existence of a single tcp (e.g.
mail) connection.

     ICMPIn: type = 5, code = 0 from 10.7.0.63  /* BBNNET2-ARPANET-GW            */
     ICMPIn: Redirect to 10.5.0.5               /* redirecting to BBN-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.5.0.5   /* BBN-MILNET-GW                 */
     ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
     ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
     ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
     ICMPIn: Redirect to 10.4.0.51              /* redirecting to SRI-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.4.0.51  /* SRI-MILNET-GW                 */
     ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
     ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
     ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
     ICMPIn: Redirect to 10.4.0.82              /* redirecting to BBN-ENET-2-GW  */

Mike

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      03 Feb 87 14:23:43 EST (Tue)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Howard Weiss <hsw@tycho.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, jim@tycho.ARPA, franceus@tycho.ARPA, lee@tycho.ARPA, jackson@tycho.ARPA, loscocco@tycho.ARPA, huckaby@tycho.ARPA, hinden@ccv.bbn.com, brescia@ccv.bbn.com
Subject:   Re: Weird Gateway Re-directs!
Howard, you seem to have captured a routing transient.

For about the past week, and through about 3pm EST Monday afternoon, there was
a growing problem with congestion on the arpanet.  Because of this congestion,
the gateways (core, butterfly, and egp) were losing track of their neighbor
connections, and making a lot of changes to the routing information they
maintain.  Between about 9am and noon EST, I had brought down various gateways
which had been providing redundant routes to satnet, wideband, and bbnnet.
Specifically, I had disconnected 8.3.0.9 (bbn2), 10.3.0.82 (bbn), 10.4.0.82
(bbn-e2), sri-wb (10.3.0.51), and css (10.2.0.25).  This was an attempt to
provide single path routes, and reduce the gateway routing overhead.  The
arpanet programmers will probably have some specific recommendations coming
out soon, because the current respite seems shaky.

For the gateways, we are designing methods to make the neighbor connections
more robust in the face of long delays, wildly varying delays, and long
internal queues.  We aim to reduce the apparent instability in the internet
when the arpanet gets congested.

--

     Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126)

This specific set of redirects would be even more interesting if we knew when
they happened.  I suspect it was around the time when I brought down the first
interface at 8.3.0.9 (other side of 10.7.0.63), around 9am EST.  Please don't
be mislead by the redirects to various other gateways; this does not mean the
packets went to the sri-ethernet, or milnet.  They went in and out the same
arpanet interface of each gateway which issued a redirect.

Additional information I could use would be how often and how long the
redirect flurry was going on.  It does seem that the route settled after only
a 'short' time.  This means that it is useful if your host retains network
route information over a longer time than the existence of a single tcp (e.g.
mail) connection.

     ICMPIn: type = 5, code = 0 from 10.7.0.63  /* BBNNET2-ARPANET-GW            */
     ICMPIn: Redirect to 10.5.0.5               /* redirecting to BBN-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.5.0.5   /* BBN-MILNET-GW                 */
     ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
     ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
     ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
     ICMPIn: Redirect to 10.4.0.51              /* redirecting to SRI-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.4.0.51  /* SRI-MILNET-GW                 */
     ICMPIn: Redirect to 10.0.0.68              /* redirecting to LBL-MILNET-GW  */
     ICMPIn: type = 5, code = 0 from 10.0.0.68  /* LBL-MILNET-GW                 */
     ICMPIn: Redirect to 10.5.0.51              /* redirecting to SRI-GW         */
     ICMPIn: type = 5, code = 0 from 10.5.0.51  /* SRI-GW                        */
     ICMPIn: Redirect to 10.4.0.82              /* redirecting to BBN-ENET-2-GW  */

Mike
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1987 at 1511-EST
From:      hsw at TYCHO.ARPA  (Howard Weiss)
To:        brescia at ccv.bbn.com
Cc:        tcp-ip at sri-nic, jim, franceus, lee, jackson, loscocco, huckaby, hinden at ccv.bbn.com
Subject:   re: Weird Gateway Re-directs!

Mike,

The redirects were received when ack packets were being sent to BBCC-COLUMBIA
in response to an smtp message that was received by TYCHO at 12:10:06 EST.
The flurry of redirects did end quickly and we do keep the redirect
state information until the network code is restarted.

Also, later in the day (after 1630 EST) there was another flurry of
redirects which lasted much longer than the one I showed in my
earlier message, but I will not send this one out because there
are several ftp connections that were being redirected and
I cannot tell which redirect is from which connection.

Howard
-------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Feb-87 17:28:37 EST
From:      hsw@TYCHO.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: Weird Gateway Re-directs!


Mike,

The redirects were received when ack packets were being sent to BBCC-COLUMBIA
in response to an smtp message that was received by TYCHO at 12:10:06 EST.
The flurry of redirects did end quickly and we do keep the redirect
state information until the network code is restarted.

Also, later in the day (after 1630 EST) there was another flurry of
redirects which lasted much longer than the one I showed in my
earlier message, but I will not send this one out because there
are several ftp connections that were being redirected and
I cannot tell which redirect is from which connection.

Howard
-------

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Feb-87 17:39:00 EST
From:      Perrine@LOGICON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   PSN physical locations?

Is there any way I can find out where the ARPA or MILNET PSN are
located?  (A file a SRI-NIC, maybe?) I am specifically interested in
the San Diego area.  I know about NOSC, are there any others?

Tom Perrine

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Feb-87 20:10:24 EST
From:      karn@jupiter.bellcore.com.UUCP
To:        mod.protocols.tcp-ip
Subject:   Inappropriate responses to broadcasts

Some time ago, there was discussion about IP implementations which respond
inappropriately to broadcast packets.  A number of solutions were offered,
the best one (in my opinion) being a flag to tell IP when a packet was
received on a hardware broadcast address so that it would not try to forward
it or respond to it with an ICMP message.

Since then, there seems to have been virtually no progress among the vendors
in implementing these fixes. Here at Bellcore we run a rather large network
consisting of Ethernets at several locations bridged together with DEC
LanBridge 100's and Vitalink Translan-3s.  With so many hosts on the same
"virtual Ethernet", from time to time broadcast packets with bogus IP
addresses are bound to appear.  Right now there is one Microvax running
Ultrix 1.2 that has its netmask set improperly. A single rwho packet from
that machine triggers literally HUNDREDS (as counted with my Excelan
Lanalyzer) of ARP requests.  This represents practically every host on the
network!!  I cringe to think that before long many more of our machines will
be running 4.3 BSD-derived code that allows the setting of the IP broadcast
address to any bogus value the heart desires.

At Uniforum in DC the other week I played with the Lanalyzer at the Excelan
booth. Guess what? Most of the packets on the net were ARP requests because
of one machine that didn't have its IP broadcast address set right!  I felt
right at home.  At least I now know what to say the next time a vendor tells
me "get our latest release and then call me back".

Before somebody tries to tell me that it's my fault for using bridges on
such a large scale, I should point out that the Vitalink boxes make it very
easy to cut off misbehaving hosts.  By entering the Ethernet address of the
aforementioned Microvax into the bridge's "twit list", the offending traffic
is isolated to one location.  Even with these problems our use of bridging
has improved our network's availability enormously over our old practice of
using UNIX machines as IP gateways.  It was worth it just to be able to
get rid of routed (RIP) for internal communications.

If something more formal than the TCP-IP archives is needed to get the
vendors to act, I hereby volunteer to write the RFC.  I would require that
the link or subnet pass a "multicast" bit to IP indicating when an incoming
packet is received on a hardware broadcast or multicast address.  If this
bit is set, IP must refuse to forward the packet or answer it with an ICMP
message.  It should also refuse to pass the packet up to TCP, should its
protocol ID appear in the header.  Naturally, the multicast bit would always
be zero for packets received on non-broadcast and point-to-point subnets.

Since there are so many incompatible conventions for IP broadcast addresses,
I suggest that they be done away with altogether.  Since gateways never
forward broadcasts, the IP destination address in a broadcast UDP packet has
no real meaning and should be ignored.  The fact that the packet was sent to
the hardware broadcast address should be enough to say "this is a broadcast
packet".

Phil

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Feb-87 01:55:58 EST
From:      scarter@CAIP.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: caip!scarter
From: scarter@caip.RUTGERS.EDU (Stephen M. Carter)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Looking for Tcp/Ip for Prime's PRIMOS system
Message-ID: <4060@caip.RUTGERS.EDU>
Date: 4 Feb 87 06:55:57 GMT
References: <8702030109.AA11365@ucbvax.Berkeley.EDU>
Reply-To: scarter@caip.UUCP (Stephen M. Carter)
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 21

In article <8702030109.AA11365@ucbvax.Berkeley.EDU> Henry Nussbacher <Hank@Barilvm> writes:
>I have seen that Prime has a Tcp/Ip version.  I am interested in hearing
>any user experience with this package - costs, benefits, pros, cons, etc.
> 
>Please reply directly to me since I am not on this list.

...Also add to this question the status of hardware the tcp uses.  When I first
asked Prime these questions, they said that tcp only interfaced to their
X.25 hardware.   Plans for an Ethernet board have not been considered (they
were thinking about OEM'ing Bridge's X.25/Ethernet gateway as this interface).

Granted this was almost two years ago, anyone know the latest?


-SCarter
uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!scarter
arpa:   SCARTER@RUTGERS or SCARTER@RED.RUTGERS.EDU

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Feb-87 13:16:23 EST
From:      rjwelsh@CCT.BBN.COM ("Robert J. Welsh")
To:        mod.protocols.tcp-ip
Subject:   re: new 32 bit address layout ?


Lars Poulson writes:

>A private communication mentioned that 
 
>> The current 32-bit address is divided into 4 fields (N,H,L,I):
>> 
>>           |   N    |    H     |    L   |    I   |
>>           |--------|----------|--------|--------|
>> 
>> The proposed division (N,H1,H2,H3,F,G,L1,I1,I2) is according to 
>> that which is to be proposed by BBN and the DDN PMO in an upcoming 
>> RFC expected out in the January timeframe:
>> 
>>          |   N   |H1     H2|H3 F|G|L1|I1|   I2  |
>>          |-------|---------|------------|-------|
>> 
>> The F field is proposed as a flag to indicate a X.25 Logical Address;
>> the G field is reserved for future use.  With Logical Addressing
>> the H field is proposed to be expanded to 10 bits (H1,H2,H3) and the
>> I field similarily (I1,I2).  With Logical Addressing, there will
>> remain a 16-bit X.25 Logical Address (H,I).  This means there are
>> 4 Internet Addresses which map to the same X.25 Logical Address
>> (those which differ only in the H3,L1, and I1 fields).  For
>> compatibility with existing DDN X.25 the H field must still be
>> greater than 64 for all X.25 Logical Addresses.
 >
>This prompts a few questions:
>
>(>1) Current address formats:
> >   I can see in HOSTS.TXT that currently class A networks based
>    on C/30 PSN's use the above format, mostly with
>    N = network number (1-126)
>    H = port number on PSN
>    L = 0 (can be non-zero with a port expander)
>    I = PSN number in network
>
>    I believe that class B networks based on BBN PSN's use
>    N,H = network number (128.1 - 191.255)
>    L = port number on PSN
>    I = PSN number in network
>
>    I don't know what format is used for class C PSN's.

PSNs  (Packet Switch Nodes - formerly IMP) do not know about IP leader classes.
Only gateways and hosts know about IP.

Class C IP address:

	|110|---------------------|--------|      
		21 bit net no.     local host

To use logical addr. with this leader limits  the  addressing  range.   When  a
gateway  translates the IP addr to 1822 or whatever, it must supply the upper 8
bits of the logical name (a constant) and use "local host" as the lower 8  bits
of the name. This leaves you with a address range of 377 (octal) hosts.



>
>(2) Logical addressing.
>    As I understand it, the above physical addressing scheme is
>    used throughout ARPAnet and MILNET; other networks use
>    "logical addressing". Software generally has to be configured
>    to know which of the two schemes is in use.
>    When a host comes up, the PSN tells it its address if the
>    network is physical, but the host tells the PSN its address
>    if the network is logical.
>
>    Physical and logical addressing cannot be mixed in the same
>    network.

Not true.  Physical and Logical addressing can coexist on the same network.
Furthermore, we can even support physical and logical addressing hosts from
the same IMP.

>
>(3) IP addresses versus AHIP addresses.
>    Logical addressing is a feature of the 1822 interface protocol
>    (AHIP) and there is a standard translation from IP to AHIP.

Logical Addressing requires the 1822L leader.

>
>(4) IP addresses versus X.25 addresses
>    The conversion between IP addresses and X.25 addresses is defined
>    in the DDN X.25 spec. so long as the class A "L" field is not used.
>    Use of bits in the IP address to trigger a request for logical
>    addresses is a new feature that may invalidate current port
>    expander implementations.
>
>(5) RFC review.
>    BBN and the DDN PMO are discussing this, but no decision will be
>    made until the RFC has had a chance to elicit comments from the
>    protocol research community ?
>
>Did I get all of that right ?



>Lars Poulsen, ACC Customer Service
 <*>

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Feb 87 13:16:23 EST
From:      "Robert J. Welsh" <rjwelsh@cct.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        rjwelsh@cct.bbn.com
Subject:   re: new 32 bit address layout ?

Lars Poulson writes:

>A private communication mentioned that 

>> The current 32-bit address is divided into 4 fields (N,H,L,I):
>> 
>>           |   N    |    H     |    L   |    I   |
>>           |--------|----------|--------|--------|
>> 
>> The proposed division (N,H1,H2,H3,F,G,L1,I1,I2) is according to 
>> that which is to be proposed by BBN and the DDN PMO in an upcoming 
>> RFC expected out in the January timeframe:
>> 
>>          |   N   |H1     H2|H3 F|G|L1|I1|   I2  |
>>          |-------|---------|------------|-------|
>> 
>> The F field is proposed as a flag to indicate a X.25 Logical Address;
>> the G field is reserved for future use.  With Logical Addressing
>> the H field is proposed to be expanded to 10 bits (H1,H2,H3) and the
>> I field similarily (I1,I2).  With Logical Addressing, there will
>> remain a 16-bit X.25 Logical Address (H,I).  This means there are
>> 4 Internet Addresses which map to the same X.25 Logical Address
>> (those which differ only in the H3,L1, and I1 fields).  For
>> compatibility with existing DDN X.25 the H field must still be
>> greater than 64 for all X.25 Logical Addresses.
 >
>This prompts a few questions:
>
>(>1) Current address formats:
> >   I can see in HOSTS.TXT that currently class A networks based
>    on C/30 PSN's use the above format, mostly with
>    N = network number (1-126)
>    H = port number on PSN
>    L = 0 (can be non-zero with a port expander)
>    I = PSN number in network
>
>    I believe that class B networks based on BBN PSN's use
>    N,H = network number (128.1 - 191.255)
>    L = port number on PSN
>    I = PSN number in network
>
>    I don't know what format is used for class C PSN's.

PSNs  (Packet Switch Nodes - formerly IMP) do not know about IP leader classes.
Only gateways and hosts know about IP.

Class C IP address:

	|110|---------------------|--------|      
		21 bit net no.     local host

To use logical addr. with this leader limits  the  addressing  range.   When  a
gateway  translates the IP addr to 1822 or whatever, it must supply the upper 8
bits of the logical name (a constant) and use "local host" as the lower 8  bits
of the name. This leaves you with a address range of 377 (octal) hosts.



>
>(2) Logical addressing.
>    As I understand it, the above physical addressing scheme is
>    used throughout ARPAnet and MILNET; other networks use
>    "logical addressing". Software generally has to be configured
>    to know which of the two schemes is in use.
>    When a host comes up, the PSN tells it its address if the
>    network is physical, but the host tells the PSN its address
>    if the network is logical.
>
>    Physical and logical addressing cannot be mixed in the same
>    network.

Not true.  Physical and Logical addressing can coexist on the same network.
Furthermore, we can even support physical and logical addressing hosts from
the same IMP.

>
>(3) IP addresses versus AHIP addresses.
>    Logical addressing is a feature of the 1822 interface protocol
>    (AHIP) and there is a standard translation from IP to AHIP.

Logical Addressing requires the 1822L leader.

>
>(4) IP addresses versus X.25 addresses
>    The conversion between IP addresses and X.25 addresses is defined
>    in the DDN X.25 spec. so long as the class A "L" field is not used.
>    Use of bits in the IP address to trigger a request for logical
>    addresses is a new feature that may invalidate current port
>    expander implementations.
>
>(5) RFC review.
>    BBN and the DDN PMO are discussing this, but no decision will be
>    made until the RFC has had a chance to elicit comments from the
>    protocol research community ?
>
>Did I get all of that right ?



>Lars Poulsen, ACC Customer Service
<*>
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 04:20:01 EST
From:      ROMKEY@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   ARP, ethernet and starlan

Here's a definition of a phrase I will use in this message. I just
want to avoid any ambiguity at the onset:

Here's a problem:

Starlan is an 802.3 network; it looks like ethernet except it's cabled
differently, it runs at 1Mbps instead of 10Mbps and (I think but I'm not
certain) it's manchester encoding is slightly different.

I need to bring up TCP/IP on Starlan, and I have a question:

What ARP hardware type should I use?

My immediate reaction is to go to the number czar and ask him to assign a
starlan number and use that. But wait...there's a catch.

Some vendors have or are developing MAC-level bridges which connect ethernets
to starlans (as well as other ethernets). For this type of connection
to work correctly, Starlan must have the same ARP hardware type as ethernet
or else machines on one net connect to another via a MAC-level bridge will
discard ARP requests because they will be for the wrong hardware type
(I assume that we *do* check this field, after all...) and no communication
will occur.

Would the number czar care to comment?

Also, does anyone know if any vendors are planning to develop an 802.3
to 802.5 MAC-level bridge? Different waveforms and different speeds, I
know, but similar packet headers.  If they are, then we've already
lost because there is already an 802.5 ARP hardware type which is
different from ethernet.  Maybe there should be an 802.x ARP hardware
type...

John Romkey			FTP Software, Inc.
(617) 864-1711			PO Box 150
UUCP: romkey@mit-vax.UUCP	Kendall Square Branch
ARPA: romkey@xx.lcs.mit.edu	Boston, MA, 02142

-------

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 11:40:50 EST
From:      ahill@CC7.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)


	In the past few days BBNCC has recorded numerous instances
of non-BBN supported gateways attempting to communicate with a non-
existent host.  The subnet only provides us with reports of attempts
which were delayed by temporary resources shortages within the ARPANET.
BBN believes that all connection attempts would return a destination
host dead (1822 type 6 subtype 9).  These attempts are being made
to address 10.3.0.52 which is currently unoccupied but used to
be USC-ISIB.  BBN estimates that there are between 200,000 and 2,000,000
attempts per 24 hour period.  BBN is not able to determine the
nature of the attempts or the originating source(s) since the origin
is behind gateways.  The following is a list of the host/gateways that
originated or forwarded traffic destined for 10.3.0.52.  Any information
on what is causing this traffic would be appreciated.  It is a likely
candidate for contributing to ARPANET congestion.

	CSNET	7/82
	RELAY 	4/5
	MITGW	0/77
	UCBAR	0/78
	UCBVX	2/78
	TUCC	6/96
	CMUD	2/14
	CORNL	3/96
	BBNMG	5/5
	TRIV	0/25
	LBMGW	0/68
	HARV	0/9
	ASC	1/37
	CUGAR	3/89
	AIGW	3/6
	SUN	7/2
	TEXAS	0/62
	UPENN	4/96
	ROCH	0/15

THE TABLE IS ORDERED BY FREQUENCY OF REPORTS.  THE TOP FOUR ARE TWO TO
FOUR TIMES HIGHER THAN THE REST.

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Feb 87 11:40:50 EST
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        mills@huey.udel.edu, arpanetmgr@ddn1.arpa
	In the past few days BBNCC has recorded numerous instances
of non-BBN supported gateways attempting to communicate with a non-
existent host.  The subnet only provides us with reports of attempts
which were delayed by temporary resources shortages within the ARPANET.
BBN believes that all connection attempts would return a destination
host dead (1822 type 6 subtype 9).  These attempts are being made
to address 10.3.0.52 which is currently unoccupied but used to
be USC-ISIB.  BBN estimates that there are between 200,000 and 2,000,000
attempts per 24 hour period.  BBN is not able to determine the
nature of the attempts or the originating source(s) since the origin
is behind gateways.  The following is a list of the host/gateways that
originated or forwarded traffic destined for 10.3.0.52.  Any information
on what is causing this traffic would be appreciated.  It is a likely
candidate for contributing to ARPANET congestion.

	CSNET	7/82
	RELAY 	4/5
	MITGW	0/77
	UCBAR	0/78
	UCBVX	2/78
	TUCC	6/96
	CMUD	2/14
	CORNL	3/96
	BBNMG	5/5
	TRIV	0/25
	LBMGW	0/68
	HARV	0/9
	ASC	1/37
	CUGAR	3/89
	AIGW	3/6
	SUN	7/2
	TEXAS	0/62
	UPENN	4/96
	ROCH	0/15

THE TABLE IS ORDERED BY FREQUENCY OF REPORTS.  THE TOP FOUR ARE TWO TO
FOUR TIMES HIGHER THAN THE REST.


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 12:08:17 EST
From:      jas@MONK.PROTEON.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   ARP, ethernet and starlan

Ah, the wonderful gifts we have received courtesy of 802.2.

If Starlan is 802.3, then you really "should" use 802.2, the same as
is used for 802.5.  Pile SNAP on top of 802.2, and away you go.  Of
course, this nails the Ethernet 2.0 people, but that's a mess we have
to face.

What ARP hardware type is being used for 802.2/802.5?  Maybe we indeed
should have a 802.2 "hardware" type.

U-B has announced an 802.3/802.5 MAC-level bridge.  It poses a lot of
interesting questions, if anyone from U-B wants to edify us it would
help iron out how we should design 802.2/SNAP/ARP.

Problems like this show the advantages of routers over bridges...

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 13:25:26 EST
From:      melohn@SUN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ARP, ethernet and starlan

> ...Maybe there should be an 802.x ARP hardware type...

From the tcp-ip archives:

Date: 12 Oct 1986 16:26:38 PDT
From: POSTEL@B.ISI.EDU
Subject: IP on 802
To: tcp-ip@SRI-NIC.ARPA


Well, i haven't got an RFC out yet, but the procedure described in the
following memo should be used anyway.  There is a small and ever
decreasing possibility that the values of K1 and K2 may be different
than indicated below, so consider the possibility of having them
changable in your implementation.

In the mean time please go ahead and use this encapsulation format for
doing IP and ARP (and other things) on 802 nets,

                      using K1=170, and K2=0.

The IEEE likes to talk about bytes in little endian order so they say
K1 is 01010101.  The ARPA protocols have everything in big endian
order so that K1 becomes 10101010 binary or AA hex or 170 decimal.
This value is pretty definite.

The value of K2 is somewhat less certain, but no evidience to the
contrary has surfaced yet.

--jon.

*** begin ***

Date: 29 Aug 1986 19:27:12 PDT
From: POSTEL@B.ISI.EDU
Subject: How to IP & ARP on 802 Nets
To:   tcp-ip@SRI-NIC.ARPA

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.

***  end  ***
-------

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1987 18:21-EST
From:      Urbaniak@G.BBN.COM
To:        dunigan@ORNL-MSR.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        Urbaniak@G.BBN.COM, rtavilla@RCCA.BBN.COM
Subject:   Re: seeking source for Ether packet types and vendor address...
This list of Ethernet vendor addresses and Type Fields includes responses
of the last week.

Current BBN Ethernet and IEEE802.3 "Type" Fields

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These are formerly assigned by
Xerox, currently assigned by IEEE. Some assignments are public, others private.
Information currently available includes: Xerox Public Ethernet Packet
Type documentation; IEEE802.3 Std, but not yet further documentation from
IEEE; NIC RFC960; knowledge of some BBN Private Type Field values.

Hex
0000-05EE	IEEE802.3 Length Field
0600	Xerox NS IDP *
0800	DOD IP * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	ARP * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine protocol? *
5208	BBN Simnet Private
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC LAT
6005	DEC protocol, at interface initialization?
6006	DEC user protocol
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8035	Reverse ARP
8038	DEC LanBridge Management
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
809B	AppleTalk over Ethernet (Kinetics only?)
9000	Loopback (Configuration Test Protocol)
FF00	BBN VITAL-LanBridge cache wakeups

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
Ethernet Vendor Addresses

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Currently we have noted the following vendor addresses, on the
BBN Corporate Ethernet.

000093	Proteon
0000AA	Xerox		Xerox machines
000102	BBN		BBN internal usage (not registered)
00DD00	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp
08001A	Data General
080020	Sun		Sun machines
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080047	Sequent
08004C	Encore
080068	Ridge
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Physical address for some DEC machines
AA0004	DEC		Logical address for systems running DECNET

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), I am unaware of the algorithm.
Current BBN Ethernet Multicast Addresses

I do not have protocol specifications for DECNET and the VALID
protocol at this time.
There is no XNS or VALID router at present; those packets might be
Hello packets, or gateway query packets.

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				lowest-addressed LanBridge
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-FF-FF-FF
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 18:38:00 EST
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   ARP, ethernet and starlan

The intention of the hardware type field in ARP packets is to
distinguish semantically different types of hardware.  If your Starlan
802.3 network is "semantically the same" as Ethernet, then for the
purposes of ARP it is Ethernet.  "Semantically the same" roughly means
"has the same number of hardware bytes in the address."  

Compare this with a 3Mbit Ethernet which has an 8 bit hardware address,
or an MIT Chaos net which has a 16 bit hardware address.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 21:45:27 EST
From:      ROMKEY@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ARP, ethernet and starlan

Um. Yes, in fact, I've implemented an 802.5 IP driver according to that
spec. I'd never read it well enough to notice that Jon Postel consistently
said "802" instead of "802.5". Then I guess all 802.mumble networks should
use the same ARP hardware type?
				- john
-------

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 21:53:09 EST
From:      ROMKEY@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ARP, ethernet and starlan

I hate to be nit picky (really, I do) but ARP has both a hardware type
field and a hardware address length field. I suppose the address length field
could be of use on networks where the hardware address was variable length?

Yes, Starlan is semantically the same as ethernet, so I according to your
argument they should have the same hardware type. I tend to agree...
				- john
-------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 22:00:48 EST
From:      ROMKEY@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   More 802.x and ethernet and ARP stuff

I guess I have two more questions:

1. Should we encapsulate IP over Starlan the Blue Book (old ethernet) way or
	the 802.2 way? I would have to argue for now to do it the Blue Book
	way because with MAC level bridges connecting an ethernet to a starlan
	the Blue Book ethernet hosts couldn't talk to the 802.2/3 Starlan hosts.

2. Awful question of the day: should we (the Internet community, etc.) ever
	ever convert to using 802.2 IP encapsulations over ethernet? If we
	don't, we're not going to find that some hosts can't talk to one
	another in certain network configurations involving MAC level bridges.
	If we do, we're probably going to suffering from the bruises for two
	or three years. If we should convert, then when?

I *am* sorry to have asked the latter question, really. But it comes up more
and more often these days.

Also, re: my first message on the topic, sorry, I was making it up as I was
going along and in one draft I decided to define some term which meant 'MAC
level bridge' and then I realized I could say 'MAC level bridge' and I left
this line at the beginning of the message saying "Let me define something to
avoid confusion: (great gaping hole)"...
					- john
-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 22:11:16 EST
From:      melohn@SUN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ARP, ethernet and starlan

Technically the "SNAP" idea applies to 802.2, the LLC(2) layer, therefore
it works on any of the MAC(1) layer media, include 802.3, .4, and .5.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Feb-87 23:38:03 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

We list ISIB as being a root domain server.  It isn't our first, so
we probably never use it.  But I'd be willing to bet that some
other sites have it listed as well, and this is a large part of the
problem.  When root domain servers are removed, I think you should
make several very prominent announcements in all possible
newsgroups.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Feb-87 05:04:36 EST
From:      MKL@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

From the list of hosts/gateways that are trying to talk to ISIB, my
guess is that most of the traffic headed there are domain server
queries.  All hosts should check their server entries to make sure
that ISIB (10.3.0.52) is no longer listed as a root server.  This was
announced quite a while ago.
-------

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Feb-87 08:40:44 EST
From:      SHEP@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   nuerous attempts to communicate with a non-existent host

I believe USC-ISIB used to be listed as a top-level domain server.  If
some hosts still contain USC-ISIB and 10.3.0.52 in their nameserver
configurations, that might explain the continued attempts to
communicate with the "non-existent host".  (I did find one host behind
MITGW for which this is true.)

-------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Feb-87 09:51:58 EST
From:      jb@cs.brown.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Packets to 10.3.0.52 (USC-ISIB)

In response to Alan Hill's remarks about a large number of packets being
sent to a decommisioned host, I suspect that the primary cause is that
USC-ISIB used to be one of the root servers for the name-domain system.
Many sights probably have not changed there configuration information
to properly reflect the change.  UC Berkeley, and CSNet are both heavy
users of the system.  There should be some attempt to notify the domain
administrators and inform them of this change.

				Jim Bloom

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Fri, 06 Feb 87 09:51:58 EST
From:      Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
To:        ahill@CC7.BBN.COM, tcp-ip@SRI-NIC.ARPA
Cc:        mills@HUEY.UDEL.EDU, arpanetmgr@DDN1.ARPA
Subject:   Packets to 10.3.0.52 (USC-ISIB)
In response to Alan Hill's remarks about a large number of packets being
sent to a decommisioned host, I suspect that the primary cause is that
USC-ISIB used to be one of the root servers for the name-domain system.
Many sights probably have not changed there configuration information
to properly reflect the change.  UC Berkeley, and CSNet are both heavy
users of the system.  There should be some attempt to notify the domain
administrators and inform them of this change.

				Jim Bloom

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Feb-87 10:03:00 EST
From:      DCP@QUABBIN.SCRC.Symbolics.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ARP, ethernet and starlan


    Date: Thu 5 Feb 87 21:53:09-EST
    From: John Romkey <ROMKEY@XX.LCS.MIT.EDU>

    I hate to be nit picky (really, I do) but ARP has both a hardware type
    field and a hardware address length field. I suppose the address length field
    could be of use on networks where the hardware address was variable length?

That, and the ability for monitors to be able to parse the
request/responses without knowing the semantics of the hardware or
software types.  (Though how it could not know the hardware type is
probably rhetorical.)

    Yes, Starlan is semantically the same as ethernet, so I according to your
    argument they should have the same hardware type. I tend to agree...
				    - john
    -------

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Feb-87 03:05:18 EST
From:      ROMKEY@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   the IEEE/Blue Book problem: an idea

I think things aren't as grim as I originally thought they were.
Here's some background, and why.

I believe we need to switch over to IEEE formats on ethernet, away
from Blue Book, IF companies are going to be selling 802.3 to 802.5
MAC-level bridges. If two machines running IP on a token ring and an
ethernet can't talk to one another via the bridge, we're going to be
shot on sight (and complained at, too). [Personally, I'd rather just
ignore the whole issue, but I think if we do then we're going
to end up with a lot of broken networks.]

I believed there was a nasty problem in converting the IP encapsulation
format, but now I think I know a way around it. The problem is that
while it's easy to receive both Blue Book and IEEE IP packets at the
same time (just accept both packet formats), it's difficult to decide
which format to transmit. You could have a switch in the operating system
or network code that sets this, but that's not good enough; it needs to be
on a per-host basis.

This had me very worried, since this sort of transition would be TRULY PAINFUL.
There would be many problems with two TCP hosts on the same cable
not being able to talk to one another, and I think it would mean
general setbacks to the TCP/IP "cause".
Then I had an inspiration based on the way that 4.3 Unix negotiates the use of
trailers.

First, add a flag to each entry in your ARP cache showing whether the host
speaks IEEE or Blue Book formats. Then, when you want to send a packet to a
host:
	1. See if the host is in your ARP cache. If it is, send the packet
	   formatted according to the setting of this flag.

	2. If it isn't, try sending an IEEE ARP at the host. If this
	   succeeds, put an entry in the ARP cache, and note that the
	   host likes IEEE formats.

	3. If it doesn't respond, try sending a Blue Book ARP at the
	   host. Again, if it succeeds, put an entry in the ARP cache
	   and note that the host likes Blue Book formats.

	4. If it doesn't succeed, then do whatever it is you do when
	   ARP fails.

Note that this algorithm only wants to be followed on an ethernet or IEEE 802.3
network, not on token ring or the other 802 networks. Also, for this to work,
all IEEE ARP packets all have the same ARP hardware type field, regardless of
which IEEE network they're on. As a side note, receivers do not distinguish
between IEEE ARP and Blue Book ARP based on the hardware types, because the
ARP's are *also* encapsulated differently in each case, so a Blue Book-only
host will throw away any IEEE ARP's it gets. This doesn't really matter,
but it might not be obvious from some of my previous messages on this
subject.

One (hopefully last) question: what would happen if a MAC-level
bridge had to forward a Blue Book packet to, say, an 802.5 ring?

Finally, I don't recommend anyone follow the algorithm I have
described above unless it receives some sort of official endoresment.

John Romkey			FTP Software, Inc.
(617) 864-1711			PO Box 150
UUCP: romkey@mit-vax.UUCP	Kendall Square Branch
ARPA: romkey@xx.lcs.mit.edu	Boston, MA, 02142
-------

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Feb-87 23:02:16 EST
From:      Mills@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Inappropriate responses to broadcasts

Phil,

The fuzzball gateways used on the NSFNET Backbone, among other places, incorporate
a "martian filter" that grounds packets for the various IP braodcast addresses,
as well as other reserved addresses (see RFC-990). At least one other gateway
system (cisco) allegedly does the same. As you know from my previous messages
to this list, gateways that forward IP broadcast packets can creat astonishing
mischief in quite surprising places.

Your suggestion on a mechanism to prevent forwarding of multicast packets was
suggested to the INENG Task Force some time back; however, implementation in
the various Unix bsd's hasn't happened yet. See also the appendix to RFC-985
for further suggestions. Your comments and advice on the issues raised there
would be welcome.

Dave

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Feb-87 12:05:25 EST
From:      richb.UUCP@seismo.css.gov@dartvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: dartvax!richb
From: richb@dartvax.UUCP (Richard E. Brown)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: network password protection/TCP spec
Message-ID: <5665@dartvax.UUCP>
Date: 9 Feb 87 17:05:24 GMT
Reply-To: richb@dartvax.UUCP (Richard E. Brown)
Organization: Dartmouth College, Hanover, NH
Lines: 30
References:

A while back, there was a discussion of protecting passwords,
which lead to a discussion of taking over someone's TCP
connection.  One person noted that if a spoofer simply startd
sending in-sequence messages, they could take over the session
and the victim would be relatively helpless.  Another person
responded that he thought TCP specified that an ACK with a
sequence number that was too high would result in a RST to clean
out the connection.  (Further discussion revealed that TCP does
*not* specify this -- in fact, it allows the session to
continue.)

My question:  Is this behavior (sending RST if the ACKs get too
high) desirable?  Are there any pitfalls to doing this?

Here at Dartmouth, we have developed a stream protocol which
runs over AppleTalk.  It is in use throughout the campus with
our Macintosh terminal emulator, and several commercial vendors
are also implementing this protocol.  If it is useful, a stroke
of a pen will implement it (well, you know what I mean).  Thanks.

Rich Brown
Dartmouth College
Kiewit Computer Center
Hanover, NH 03755
603/646-3648

richb@dartmouth.edu
richb@dartmth.bitnet
richb@dartvax.UUCP
A0183 on AppleLink

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Feb-87 00:50:20 EST
From:      km@EMORY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Telnet Wish List

Our Broadband vendor (Applitek) has agreed to add Telnet (and tcp/ip)
to their terminal NIU product.  The idea is that terminals connected to
an NIU could initiate a telnet session which would then be bridged to
ethernet via their bband/ethernet bridge product. I suppose the ip
packets would be encapsulated in their proprietary Unilan packets, and
stripped out at the bridge. On the surface it should give the
appearance of one of the ethertip boxes (like Annex or Cisco).

Anyway, we would like to give the vendor a wish list.  I would
appreciate any suggestions of features we should emphasize, and
pitfalls we should avoid.

One specific point for comment is the advisability of telnet instead of
rlogin. Can a well implemented telnet work as well as rlogin? Is the
rlogin protocol documented, or is the protocol just what the code
does?

I have seen some reference to adding facilities to the NIU to offload
the host (hooks to editors, cooked mode done in the niu, etc..). Are
any of these really big wins? The job of patching and maintaining the
host software to support this (let alone convince the vendor to do the
NIU side) seems to be only worth doing if the improvement is great.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue 10 Feb 87 11:07:05-PST
From:      CONTR14@NOSC-TECR.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Please add to mailing list

Please add this net address to the tcp-ip mailing list.

-------------------------------------------------------------------
Thanks in advance,

James Baldo Jr.
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Feb-87 10:16:00 EST
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Telnet Wish List


    Date: Tue, 10 Feb 87 00:50:20 EST
    From: Ken Mandelberg <km@EMORY.ARPA>

    One specific point for comment is the advisability of telnet instead of
    rlogin. Can a well implemented telnet work as well as rlogin? Is the
    rlogin protocol documented, or is the protocol just what the code
    does?

Yearly TELNET flame: TELNET is a piece of junk designed for ASR33s and
later tried to get improved as terminals entered a more modern age.  Use
SUPDUP (RFC 734).  If you also want to do graphics, see the SUPDUP
graphics protocol (RFC 746).

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Feb-87 14:07:05 EST
From:      CONTR14@NOSC-TECR.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Please add to mailing list


Please add this net address to the tcp-ip mailing list.

-------------------------------------------------------------------
Thanks in advance,

James Baldo Jr.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 10 February 1987 14:12:06 EST
From:      Rudy.Nedved@h.cs.cmu.edu
To:        Ken Mandelberg <km@emory.arpa>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Telnet Wish List
Telnet can work as well as rlogin except for the extra step of logging
in which rlogin does for you. In a place where many hosts exists and
security is an issue, rlogin mechanism will have to be revised creating
yet-more incompatibilities. Whereas the concept of a remote terminal
connection does not have any potential future problems other then 
supporting graphics which should be a new protocol to begin with.

Alas, the problem with telnet is that many people did not understand
what was going on. Various implementors misread or totally blew
the implementation of a option(s) in telnet. This shows up very quickly
when you have a variety of operating systems in your shop. 4.3BSD has
fixed alot of problems but there are still a few left around. The
best implementation (ignoring performance) seems to be TOPS-20.

The areas of weakness are:
	8-bit wide connections (binary option)
	EOL handling (CR maps to CR NUL or CR LF?)
	the ability to abort pending output buffered in 4 to 8k of buffers
	    quickly (Abort Output telnet command and Data Marks).
	proper handling of option negotiations.
	user settable options (remote versus local echo/editting, allowing
	   or not allowing binary).

CMU does not use rlogin and has several different implementations of telnet
and several different types of crazy terminals. Before many products were out,
we created our own TELNET box or whatever you call something that enables many
terminals to talk over the ethernet to a bunch of hosts. We have not seen
many complaints....except by hardcore Unix hackers who must have vanillia
Unix (whatever that is) and want rlogin and rsh.

The exception is the IBM world....we are just starting to get involved
with that stuff and have basically being using Wisconsin and Berkeley
tn3270 program on Unix and ignoring the issue on the rest of our machines.

-Rudy
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Feb-87 14:34:19 EST
From:      narten@PURDUE.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   UDP vs. ICMP dest unreachable messages

This note is prompted by the observation that lots of nameservers
still contact usc-isib (10.3.0.52), even though the machine no longer
exists.

A related problem that is appearing a lot more now has to do with
reactions in general to ICMP dest unreachable messages. Now that name
server traffic is picking up, it really hurts to see UDP
implementations ignoring ICMP errors. It is not uncommon to see half a
dozen (or more) packets sent to some remote nameserver even though the
first packet causes an ICMP dest unreachable to be returned. In some
cases this is not too serious (but still undesirable), since the
message comes from a gateway one hop away with a LAN in between. Other
times, the message comes from some distant gateway on the other side
of the ARPANET.

The problem with letting UDP see these errors lies with the stateless
nature of datagram delivery at that level. With TCP, there has to be a
connection block that the error packet can be matched up against.
Hence, TCP can do something intelligent (but often doesn't). With UDP,
the packet gets sent with no guarantees about delivery.  Furthermore
the user process might well be sending data to several destinations
via the same "socket", and it is not clear how to return errors to the
user.  I see three basic approaches.

1) Do nothing, a favorite among current implementations.

2) Pass errors back to the user process. This is hard to do, since the
kernel may well have no idea of what process sent the packet. In some
cases, the kernel would have to keep a log of all UDP packets it sends
in order to pass back errors to the user.

3) Cache errors in the routing tables for short periods of time. This
can be done by adding a flag to route table entries that says "Not
really reachable".  That way, the user would not get an error on the
first packet, but the retransmission of that packet could cause the
route lookup to note that the destination is unreachable and the user
could be informed.  This would be a significant improvement because
now the user process could elect to use a different address as the
jprimary. Furthermore, the user process could elect not to use the "bad
route" for a long time (say 30 minutes or several hours), long after
the record of the unreachable message has been flushed from routing
tables. 

This has the desired effect of:

1) Processes using UDP can get feedback about unreachable 
destinations.

2) It doesn't drastically change the semantics of the UDP interface.
E.g. the user is not notified asyncronously or forced to ask
explicitely whether a route works. On return from the sendpacket()
routine, a flag could be returned.  In addition, sending packets to an
unreachable destination doesn't have to mean that the packet didn't
get sent, it just means "I got an dest unreachable a while ago. It is
not likely that the packet will get there". The user can choose to
ignore this (though he/she really shouldn't).

3) The length of time dest unreachable messages are cached can (and
probably needs to be) an adjustable parameter. It may well be that
caching such a message for 10-30 seconds would be sufficient to cut
down on the number of useless packets sent, yet would not keep users
from reaching hosts that were down but just came back up.

4) Programs don't have to rely on timeouts to decide that a host or
list of hosts is unreachable. This will often times give users a
quicker response. 

Comments?

Thomas

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 87 17:55:00 PST
From:      <art@acc.arpa>
To:        "iso" <iso@nrtc>
Cc:        tcp-ip@sri-nic
Subject:   X.25 service binding

I'd like to solicit any input anyone might have...

I'm going to be defining an X.25 service interface and am dealing
with specifying binding information for incoming calls.  Unfortunately
X.25 does not have any clean, well defined mechanism for this.
What I want is for a user to allocate a "Service Access Point" (SAP)
and then specify information for a binding filter.  When an incoming
call matches the binding filter, an Indication of Incoming Call will
be passed to the user for his acceptance or rejection.

Issues:

Protocol Identification -  The first byte of call user data is typically
used to identify a specific upper layer protocol.  But call user
data is optional and CCITT PAD protocols use a four byte protocol
identifier and other protocols (such as DoD IP) use just one.  What
about information in the rest of the user data field?

Destination Address - The format of the X.25 address which is received
is essentially controlled by the network provider under X.121 guidelines.
Some networks support "sub-address" bits which are not interpreted by
the network, others do not.  Some networks support more than one address
format (typically for local vs internetwork calls).

Source Address - Should the service interface filter on remote host
identification?

Facilities -  Should the service interface be involved in which facilities
are allowed?  What about negotiated Facilities (such as packet size)?

Anyone interested in this stuff???

						Art Berggreen
						<Art@ACC.ARPA>

------
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Feb-87 15:43:23 EST
From:      ROODE@BIONET-20.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   root domain servers

Are there enough of them?  The recent problems with the former
USC-ISIB would seem to indicate undesirable concentrations
of heavy network overhead traffic may be occurring around
the hosts which feature root domain servers.  Couldn't
this load easily be spread around?
-------

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Feb-87 20:55:00 EST
From:      art@ACC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   X.25 service binding


I'd like to solicit any input anyone might have...

I'm going to be defining an X.25 service interface and am dealing
with specifying binding information for incoming calls.  Unfortunately
X.25 does not have any clean, well defined mechanism for this.
What I want is for a user to allocate a "Service Access Point" (SAP)
and then specify information for a binding filter.  When an incoming
call matches the binding filter, an Indication of Incoming Call will
be passed to the user for his acceptance or rejection.

Issues:

Protocol Identification -  The first byte of call user data is typically
used to identify a specific upper layer protocol.  But call user
data is optional and CCITT PAD protocols use a four byte protocol
identifier and other protocols (such as DoD IP) use just one.  What
about information in the rest of the user data field?

Destination Address - The format of the X.25 address which is received
is essentially controlled by the network provider under X.121 guidelines.
Some networks support "sub-address" bits which are not interpreted by
the network, others do not.  Some networks support more than one address
format (typically for local vs internetwork calls).

Source Address - Should the service interface filter on remote host
identification?

Facilities -  Should the service interface be involved in which facilities
are allowed?  What about negotiated Facilities (such as packet size)?

Anyone interested in this stuff???

						Art Berggreen
						<Art@ACC.ARPA>

------

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Feb-87 22:05:18 EST
From:      steve@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Submission for mod-protocols-tcp-ip

Brian -

        If you run the TCP/IP protocols, you can connect your
campus to the nationwide NSFNET and gain access to lots of other
supercomputers besides your own, a transparent interconnection to
the ARPANET (and CSNET too, for that matter), and all the other
interesting things that go with Internet membership.

        It's even possible to apply for an NSF grant to connect
up.  If you're interested, drop me a note with your Snail Mail
address and ask for the "Connections Program Announcement".

        -s

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 03:04:13 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  UDP vs. ICMP dest unreachable messages

You suggest that the kernel should remember destination unreachable
messages, and not bother to try again for some time.  The problem
with this is that there are often transient routing problems.  If
you try again, things might actually work.  Until the core gets
more reliable, I would rather retry. Indeed for a while we
intentionally broke our TCP code so that it would keep trying when
it got destination unreachable, instead of aborting the connection.
This helped us keep connnections up to certain hosts.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Feb 87 08:22:13 -0500
From:      Craig Partridge <craig@loki.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Detecting Congestion

    I seem to recall hearing or seeing a note that suggested that
someone had shown that timers gave sufficient information to detect
congestion.  If anyone knows the reference(s) could you send it to me?

Thanks,

Craig
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 08:54:38 EST
From:      craig@LOKI.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Detecting Congestion


    I seem to recall hearing or seeing a note that suggested that
someone had shown that timers gave sufficient information to detect
congestion.  If anyone knows the reference(s) could you send it to me?

Thanks,

Craig

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 09:22:20 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: UDP vs. ICMP dest unreachable messages

> (you can ignore an 'unreachable' because it may indicate a transient
>  routing problem) [paraphrased - mb]

You really need to be advocating to look at the subcodes returned by ICMP
destiination unreachable, because you can usually trust the 'host dead' type
returned from some gateways when trying to talk to hosts on arpanets.  Yes,
you would do well to ignore ICMP net unreachable if you suspect routing
flurries (often the case nowadays).  With UDP domain lookups however, could
you not use that as an indication to try another address, even if you keep
retransmitting to the original one?  You need not worry about "bothering" too
many servers in this case, because the 'unreachable' is a response which tells
you that you did not reach that server.

Also, you should be explicit in your reasoning about the 'port unreachable'
subcode.  Do you mean to try again because the server too busy and did not get
another server listen up again, or give up because there is not now nor will
there ever be a server at that host (because the service host changed).

I think you should use the broadcast approach for connection setup, since you
supposedly don't care which of the equivalent servers you reach.  If, for
example, you try to contact one from the set { A, B, C }, and you get an
unreachable from A, try B next, and only forget A if the reply code was 'host
dead'.

Of course, your implementation on the arpanet (AHIP) interface does recognize
arpanet host-dead messages, doesn't it?

mike

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 87 09:22:20 EST (Wed)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Charles Hedrick <hedrick@topaz.rutgers.edu>
Cc:        narten@purdue.edu, tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com
Subject:   Re: UDP vs. ICMP dest unreachable messages
> (you can ignore an 'unreachable' because it may indicate a transient
>  routing problem) [paraphrased - mb]

You really need to be advocating to look at the subcodes returned by ICMP
destiination unreachable, because you can usually trust the 'host dead' type
returned from some gateways when trying to talk to hosts on arpanets.  Yes,
you would do well to ignore ICMP net unreachable if you suspect routing
flurries (often the case nowadays).  With UDP domain lookups however, could
you not use that as an indication to try another address, even if you keep
retransmitting to the original one?  You need not worry about "bothering" too
many servers in this case, because the 'unreachable' is a response which tells
you that you did not reach that server.

Also, you should be explicit in your reasoning about the 'port unreachable'
subcode.  Do you mean to try again because the server too busy and did not get
another server listen up again, or give up because there is not now nor will
there ever be a server at that host (because the service host changed).

I think you should use the broadcast approach for connection setup, since you
supposedly don't care which of the equivalent servers you reach.  If, for
example, you try to contact one from the set { A, B, C }, and you get an
unreachable from A, try B next, and only forget A if the reply code was 'host
dead'.

Of course, your implementation on the arpanet (AHIP) interface does recognize
arpanet host-dead messages, doesn't it?

mike
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 1987 09:43-EST
From:      CLYNN@G.BBN.COM
To:        narten@PURDUE.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: UDP vs. ICMP dest unreachable messages
Thomas,
	A couple questions about method 2: why is it so hard for the
kernel to pass the packet back to the user process?  It doesn't seem
very likely that some application would send a UDP packet and not let
the kernel know how to get the reply back to it --  your favorite
kernel does have sockets doesn't it?  The ICMP error messages contain
the IP header plus 64 bits of the packet it is complaining about.
That information is as reliable as anything that one finds in a
UDP packet -- it is covered by a checksum.  Use the information
in the included packet to find the identity of the SOURCE and
have the kernel do whatever it would normally do for a received
UDP packet with the same DESTINATION, including the mechanism for
passing it back to the application.  We have been using such a
mechanism on the TOPS20s for several years and not had any problems;
there is an option associated with the "socket" which allows the
application to specify if it wants to receive the ICMP messages or
not.

The ideas you present in 3 would be useful, especially for those
applications which haven't (yet?) been written to deal with their
errors.

Charlie
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Feb 87 10:47:05 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        hedrick@topaz.rutgers.edu
Cc:        narten@purdue.edu, tcp-ip@sri-nic.arpa, pogran@ccq.bbn.com
Subject:   Re:  UDP vs. ICMP dest unreachable messages
The issue here is one of local vs. global optimization.  The
approach of not trying for awhile to reach a destination
previously noted to be unreachable tends to reduce traffic
on the Internet; the approach of continuing to try because it
"tends to keep your connection up" is good for an individual but
lousy for the Internet because it adds traffic.  The former is a
global optimization, the latter a local optimization.

The ARPANET, in particular, is really struggling to carry the
traffic it's being offered.  Until more capacity can be added to
it (which IS in the works; the wheels of DCA may grind slowly,
but they ARE grinding in a forward direction!) the Internet
community as a whole would be better served by folks taking more
of a global optimization approach.  Namely, if you're having
trouble getting through, it's probably because the world is
congested, and repeated attempts will hurt, not help, the overall
situation.

Ken Pogran
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 13:44:41 EST
From:      haas%utah-gr@UTAH-CS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: X.25 service binding

In article <8702110223.AA26394@ucbvax.Berkeley.EDU>, art@ACC.ARPA writes:
> 
> I'm going to be defining an X.25 service interface and am dealing
> with specifying binding information for incoming calls.  Unfortunately
> X.25 does not have any clean, well defined mechanism for this.
> ...
> Protocol Identification -  The first byte of call user data is typically
> used to identify a specific upper layer protocol.  But call user
> data is optional and CCITT PAD protocols use a four byte protocol
> ...

Actually the situation is manageable.  My X.25 implementation for the
DEC-20 (RIP) checked that the Call User Data field was present and
started appropriately before accepting the call.  This seems to be
a reasonable general strategy.  You won't find many PADs supporting
X.29 that don't say so in their Call User Data field.

> Destination Address - The format of the X.25 address which is received
> is essentially controlled by the network provider under X.121 guidelines.
> Some networks support "sub-address" bits which are not interpreted by
> the network, others do not.  Some networks support more than one address
> format (typically for local vs internetwork calls).
> 
Yup.  Some networks let the caller set the sub-address bits, and some
service organizations (like STN for example) select a service based on
these bits.
>
> Source Address - Should the service interface filter on remote host
> identification?
>
You WILL find PADs that don't provide a source address, and there is
nothing in general to stop somebody from spoofing source address, unless
you happen to be hooked to a particular network that verifies this field.
In particular our local PDN, ComWest, uses Dynapac PADs that leave out
source address.
> 
> Facilities -  Should the service interface be involved in which facilities
> are allowed?  What about negotiated Facilities (such as packet size)?
> 
Well, at some level you need to negotiate facilities based on what service
is requested.  Larger window sizes have advantages for interactive use,
and larger packet sizes have advantages for file transfer.  Plus, your
accountant probably has an interest in who pays for the call, which is
a facility!
>
> Anyone interested in this stuff???
> 
> 						Art Berggreen
> 						<Art@ACC.ARPA>
Me for one!

Walt Haas
<haas@utah-cs.arpa>    ...utah-cs!haas

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 15:15:10 EST
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: UDP vs. ICMP dest unreachable messages

ICMP unreachable messages are reported to users of UDP sockets in 4.3
if and only if the socket is "connected"; that is, that the remote
address is bound as well as the local address.  Otherwise, it is unreasonable
to report errors even though the local address matches that in an ICMP
error message.  The error may well refer to a datagram other than the most
recently sent, in which case it is likely to be confusing at best.

This is used in the UNIX resolver code to detect the abscence of a local
server; it depends on receiving the "port unreachable" error.  On the other
hand, the same binding causes late messages from one server to be discarded
after "connecting" to the next of a series of choices.  This isn't a problem
in the standard installation, with only one server choice (the server on the
same host).  The UNIX nameserver does not take advantage of ICMP error returns,
in part because it runs multi-threaded, processing other requests while
awaiting a reply to a recursive query.  However, recent additions to the BIND
server will enable it to measure response time of multiple servers for a domain.
It will then choose the fastest server, which will not include one that
was recently unreachable if there are alternatives.

Recent questions about the ordering of root servers in BIND configuration
files are no longer interesting.  Current servers use the configuration
file to reach the root servers initially, which they then query about
the root domain.  That information is then used as long as it is valid.

		Mike

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 16:24:18 EST
From:      nowicki@SUN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Congestion

I am not sure which is the right group for this discussion, but the
recent congestion problems have brought up two important points.

First, the MX record support from Berkeley for sendmail does not do any
caching.  Perhaps they thought the local name server would cache, but
not when the desired name server is down.  For example, last week
Decwrl.DEC.COM was essentially unreachable from the Arpanet.  The
DEC.COM name servers are either on the other side of Decwrl (128.45),
or behind other unreliable gateways (net 36).  Thus mail started to
pile up, and we quickly had hundreds of messages sitting in the queue.
Each run through the queue did hundreds of MX lookups which had to
timeout.  I extended our simple cache (which already remembered if
hosts are up or down) to cache the result of the MX request (especially
if the request timed out).  This got the queue flowing again.

Second, there seems to be a bug in the HDH code of the PSNs (aka
IMPs).  During periods of congestion, the HDLC layer blocks us from
sending back the "Host Up" messages that are required in HDH.  The PSN
then declares us to be down, clears its buffers, then immediately hears
the Host Up message and declares us to be back up.  This happens every
few minutes during the day.  Not only does throwing the buffered data
away increase congestion in the short term by causing more
retransmissions, there are higher-level instabilities.  If a host
tries to send us a TCP segment  or ACK during the time that the IMP
thinks we are down, they get a "Host Dead" message and reset the TCP
connection, which means the entire mail message has to be
retransmitted.  This just makes matters worse.

I have tried to contact BBN about the second problem, since it is a bug
in their software, but I keep getting the run-around.  The NOC people
just say "must be congestion".  I KNOW it is congestion, but it still
is a bug!  Does anyone at BBN read these lists?

	-- Bill Nowicki
	   Sun Microsystems

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 21:09:36 EST
From:      JBVB%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Telnet parity, etc.

A couple of weeks ago, I posted a query about Telnet implementations
that sent Ascii with bit 8 set (parity, or whatever).  The question
was brought on when I ran across code that religiously masked off
the high bit before passing it to a PC's display.

  Sun's PC NFS Telnet client (VT100 emulator) is said to send parity.

  Unspecified Unix 'getty' programs make the Telnet server send parity,
  which goes away once you're logged in.

  TOPS-20 systems have a transparent mode, used by terminals where the
  8th bit is significant, but you only get it when you request it.

  When connected to a TOPS-20 system, if you use 'SET HOST' to reach
  another host via DECNET, any parity that DECNET sends gets passed
  through the Telnet server to you.

I am still interested in more details re: the Unix 'getty', as it seems
to be the major offender among servers.  Which Unices?

jbvb@ai.ai.mit.edu
Jammes B. VanBokkelen
FTP Software Inc..

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Feb-87 22:39:35 EST
From:      Mills@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  UDP vs. ICMP dest unreachable messages

Charlie,

I know the TOPS-20s have been sorting ICMP messages to the right processes
for years, since that's where I got the idea to do the same thing in the
fuzzballs. Having said that, it's too bad the users at the top of the
TOPS-20 protocol stack don't see the information itself - say in TELNET
or FTP.

Dave

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Feb-87 06:23:14 EST
From:      brady@DCN9.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  UDP vs. ICMP dest unreachable messages

I came in on this discussion a little late, so pardon me if I'm 
a little off topic...

> The problem with this is that there are often transient routing 
> problems.  If you try again, things might actually work.  Until 
> the core gets more reliable, I would rather retry. Indeed for a 
> while we intentionally broke our TCP code so that it would keep 
> trying when it got destination unreachable, instead of aborting 
> the connection.  This helped us keep connnections up to certain 
> hosts.

If you adopt this practice, you negate the purpose of the message. 
So why is it sent in the first place? In the long run, ignoring 
control messages like these could undermine any sort of development
on the internet, particularly in relation to gateway to gateway 
communications. It may seem that some benefit is gained in certain
instances from ignoring unreachable messages. But if there is to 
be a "standard" protocol, such a change would have to be beneficial
(or at least non-detrimental) to the majority of the cases. I believe
that in most cases, the control messages are a necessary factor in 
the control of needless congestion across an already strained internet.


							-Sean
 

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Feb-87 07:51:40 EST
From:      mike@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   IP Record Route in core?

Phil Dykstra at BRL has just instrumented a version of my PING
program for BSD UNIX to optionally issue the ICMP ECHO REQUEST
packets with IP Record Route enabled.  This has brought up
several important issues:

*)  The core gateways do not record any route information, although
they don't choke on the IP option.  Is there any chance that they
can be induced to store their address in the record route record,
or is this another "wait for the Butterfly gateway" issue?
In the BRL gateway, the IP Record Route code is about 20 lines of C...

*)  There is some ambiguity as to how to interpret the combination
of ICMP ECHO REQUEST and IP Record Route together.  The Mills Fuzzball
software seems to regard the ICMP ECHO REPLY as a separate transaction,
and resets the Record Route pointer to the beginning of the log area,
while the BRL Gateway presently continues recording, so you see
the full route, round trip.  There is merit to both, is one considered
"right"?

*)  4.2 BSD UNIX, alas, can't handle the Record Route at all.

*)  4.3 BSD UNIX answers, but strips off the Record Route when answering.
(Actually, it strips all options except source routing).  This is sub-
optimal, and we will be working on a fix.

*)  Checksum fixes to the BRL Gateway IP Options code were needed too.

If you want the code, (a) please wait a few weeks before asking, and
(b) don't ask me, ask <Phil@BRL.ARPA>.
	Best,
	 -Mike

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Feb-87 09:25:51 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: IP Record Route in core?


     *)  The core gateways do not record any route information,

This was a conscious design decision, not to look at any packets which do not
have the IP destination = 'the gateway'.  Well, that's not the whole case,
because the lsi11 gateways will do IP header checksum and other validity
checks, but they will not examine the options unless fragmentation is needed.

The tradeoff was between speed and functionality.  At that time, probably 4
years ago, we went for speed.  At this time, the answer is, "wait for the next
generation".  When faced with the same decision in the butterfly, I lost the
argument, so that will (does?) do record route, but at the expense (for
packets with record route option only) of extra processing at each hop,
because no shortcuts are taken past the full IP network routing.

Note that Source route does have a record route trailer.

     In the BRL gateway, the IP Record Route code is about 20 lines of C...

I expect the 11 could do it with 40 lines of macn11 ... (but it would be wrong).

     *)  There is some ambiguity as to how to interpret the combination
     of ICMP ECHO REQUEST and IP Record Route together.  The Mills Fuzzball
     software seems to regard the ICMP ECHO REPLY as a separate transaction,
     and resets the Record Route pointer to the beginning of the log area,
     while the BRL Gateway presently continues recording, so you see
     the full route, round trip.  There is merit to both, is one considered
     "right"?

This could become an emotional issue of 'right vs. wrong' but I think that
more information is provided by NOT resetting the pointer.  By the way, should
the echoing host also do a record route?  Remember it's a host, not a gateway
function.

Mike B.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 87 09:25:51 EST (Thu)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Mike Muuss <mike@brl.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, Support@brl.ARPA, brescia@ccv.bbn.com
Subject:   Re: IP Record Route in core?

     *)  The core gateways do not record any route information,

This was a conscious design decision, not to look at any packets which do not
have the IP destination = 'the gateway'.  Well, that's not the whole case,
because the lsi11 gateways will do IP header checksum and other validity
checks, but they will not examine the options unless fragmentation is needed.

The tradeoff was between speed and functionality.  At that time, probably 4
years ago, we went for speed.  At this time, the answer is, "wait for the next
generation".  When faced with the same decision in the butterfly, I lost the
argument, so that will (does?) do record route, but at the expense (for
packets with record route option only) of extra processing at each hop,
because no shortcuts are taken past the full IP network routing.

Note that Source route does have a record route trailer.

     In the BRL gateway, the IP Record Route code is about 20 lines of C...

I expect the 11 could do it with 40 lines of macn11 ... (but it would be wrong).

     *)  There is some ambiguity as to how to interpret the combination
     of ICMP ECHO REQUEST and IP Record Route together.  The Mills Fuzzball
     software seems to regard the ICMP ECHO REPLY as a separate transaction,
     and resets the Record Route pointer to the beginning of the log area,
     while the BRL Gateway presently continues recording, so you see
     the full route, round trip.  There is merit to both, is one considered
     "right"?

This could become an emotional issue of 'right vs. wrong' but I think that
more information is provided by NOT resetting the pointer.  By the way, should
the echoing host also do a record route?  Remember it's a host, not a gateway
function.

Mike B.
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 1987 17:33-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        nowicki@SUN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Congestion
Ask and ye shall be answered.  I am sending your last note to the
OPs people with the STRONG recommendation it  be  entered  as  an
"incident report" (i.e.  bug report).

Mike StJohns
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Feb-87 16:33:37 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Congestion (HDH blocking)


>     Second, there seems to be a bug in the HDH code of the PSNs 
 
>     I have tried to contact BBN about the second problem, since it is a bug
>     in their software, but I keep getting the run-around.

Bill,

To answer the specific question, you should call the NOC and refer to
SR-86-03583 (eighty-six dash zero-three-five-eight-three).  This is a previous
report of the same problem, and they should be tracked together.  For some
reason, what you said and what they heard were not sufficient to make the
connection.

In general, if the people you talk do not understanding what you are
saying, you need to talk to someone who does.  I don't think that sort of
escalation path exists yet in the call-in procedures.  It probably should.

I would prefer to see problems like this solved before you have to get up in
the widest possible forum and shout.  This shout should lead to the fix for
your problem, however, so keep in mind

"If you don't get grease, squeek louder."  - paraphrase from A. Wheel

regards,
Mike

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 87 16:33:37 EST (Thu)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Bill Nowicki <nowicki@sun.com>
Cc:        bind%arpa.berkeley.edu@bbn.com, tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com, control@ccv.bbn.com, clynn@ccv.bbn.com, cgarrison@ccv.bbn.com
Subject:   Re: Congestion (HDH blocking)

>     Second, there seems to be a bug in the HDH code of the PSNs 

>     I have tried to contact BBN about the second problem, since it is a bug
>     in their software, but I keep getting the run-around.

Bill,

To answer the specific question, you should call the NOC and refer to
SR-86-03583 (eighty-six dash zero-three-five-eight-three).  This is a previous
report of the same problem, and they should be tracked together.  For some
reason, what you said and what they heard were not sufficient to make the
connection.

In general, if the people you talk do not understanding what you are
saying, you need to talk to someone who does.  I don't think that sort of
escalation path exists yet in the call-in procedures.  It probably should.

I would prefer to see problems like this solved before you have to get up in
the widest possible forum and shout.  This shout should lead to the fix for
your problem, however, so keep in mind

"If you don't get grease, squeek louder."  - paraphrase from A. Wheel

regards,
Mike
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Feb-87 02:29:13 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   TELNET implementations


     I'd like to thank Rudy Nedved for the complement ("the best
implementation [of TELNET] (ignoring performance) seems to be TOPS-20")
since I wrote the TOPS-20 client TELNET.  After having written three
client TELNET implementations for different operating systems and a
server TELNET, it sort of rubs off on you.

     I would not say that the TOPS-20 server TELNET is anything to
rave about though.  It is unnecessarily complicated and has several
major bugs.  To my knowledge, the only implementation of TOPS-20
server TELNET that *correctly* implements TELNET protocol is the
one on SIMTEL20, STL-HOST1, and DREA-XX.  The typical bugs are the
ones Rudy noted: incorrect implementation of binary mode, EOL's, and
FFh data characters.  Some systems, such as Stanford and CMU, have
some half-assed fixes to some of these bugs; but a comprehensive fix
has been stymied to date.  It is also pretty poor that few systems
allow user program control of network binary mode.  Certain programmers
have gone as far as exploiting a bug with incorrect handling of FFh
data characters to send TELNET protocol as data!

     TOPS-20 client TELNET performs well; I think Rudy's performance
comment was aimed at the server.  My advice to implementors is:
 . you must take NO for an answer in any option
 . you must never confirm a negotiation to a state you are already in
 . run your streams in separate processes
 . never block for a protocol negotiation
 . do buffered instead of byte I/O and allocate very large buffers
 . fix your operating system's handling of Urgent data so it reliably
   works, and make your TELNET implementation use it.

     My favorite way of handling options is to SET the option state
when I send a protocol command and proceed as if the host confirmed.
The host will either:
 . confirm it, in which case all is well
 . do nothing, in which case you're still operating
 . deny it, in which case you clear the option and respond
It isn't all that bad to be mistakenly in remote echo to a system that
refuses to do so for a few seconds.

     This isn't quite according to spec, but it is a LOT better than a
bogus implementation of the protocol!  Entirely too many bogus protocol
implementations are out there.
-------

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 1987 11:21-EST
From:      CLYNN@G.BBN.COM
To:        brescia@CCV.BBN.COM
Cc:        mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA Support@BRL.ARPA
Subject:   Re: IP Record Route in core?
Re:

>    When faced with the same decision in the butterfly, I lost the
>    argument, so that will (does?) do record route, but at the expense ...

I just tried the record route option through the Butterfly Gateways at BBN
(via BBNNet & Corporate Enet & WidebandNet) and did not get anything
recorded in the record route option either when there was no simultaneous
source route option, or when there was a source route which specified the
butterfly as one hop on the route (the butterfly did record itself in the
source route in this case, however).  It would thus appear that the answer
to the "(does?)" is NO.

Re:
>    *)  There is some ambiguity as to how to interpret the combination
>    of ICMP ECHO REQUEST and IP Record Route together. ...

I agree that NOT resetting the pointer provides more information,
especially when the route taken TO a "host" may well be different than
the route taken FROM there.  Resetting the pointer flushes the TO
route; if the reset choice is "official", then I would like to see a
corresponding "official" specification of a way to get the route TO a
"host".  (Note that finding a "good" host to use was not easy -- the
local Symbolics and Vaxen dropped the option completely while the Suns
failed to return an echo-reply.)

Re:
>    By the way, should the echoing host also do a record route?

The IP spec says that the options have to be processed "When an
IP module routes a datagram...".  Part of sending a datagram is to
route it to the next hop.  Consequently the echoing host is required
to insert the interface address it uses to send the datagram in any
(strict/loose) source route or record route options that are present.

[Since a gateway which receives a datagram also has to find the next
hop and interface that should be used to send it, it is an "IP module
routing a datagram".  I would thus argue that there is no "tradeoff"
allowed; the choice is either between an implementation which does
not meet the IP protocol specification, or one which does.  I guess
that the lesson to be learned is that writing the specs is NOT an
easy task, and that we will have to try harder in the future.]

Charlie
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Feb-87 12:54:20 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  IP Record Route in core?

Mike,

Yes, this is an old entry on my punch list: should an ICMP echo reply
recompute the route (fuzzball), go back the way it came (TOPS-20),
continue the route (?) or whatever. It may be time to reconsider
these issues carefully, since the recent congestion problems may well
be resolved using these tools. Onceuponatime I thought the cleverest
way to do this was to copy the inbound ICMP request into the data portion
of the requrst, then construct a new ICMP reply header, but only if the
request had a data portion large enough for the purpose. Then, Jerry
Saltzer at MIT beat me up, because he expected the data portions to
be returned unmodified. And so it goes.

Ahem, the fuzzies don't do the record route thing to spec anyway, since
they record the inbound address, not the return address of the outbound
packet. Finally, I thought the record route magic did in fact work for
the LSIways. At least the source route spells do.

Dave

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Feb-87 15:20:18 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   ICMP messages

Here are some thoughts based on those of Dave Clark in RFC-816, which I
think is still well worth reading.

When the network breaks, a real-time human user may or may not be involved
(e.g., Telnet vs. a background mail transfer).  In the former case, you
should let the user know what's happening (i.e., show him ICMP messages)
*but* you should leave it up to him as to what to do. If he wants to wait
indefinitely until things get better, he should have that option.

In the case of two computers talking, what's the hurry?  One of the major
virtues of a (properly programmed) computer is patience. If a SMTP session
gets stuck, why not just let TCP keep trying "forever", provided that it
backs off its retransmissions enough to prevent network congestion?  Keep
the ICMP messages around for debugging, but let TCP do its job instead of
giving up and forcing the application to start all over again.  Your mail
daemon is going to be sending out connection requests every hour or so
anyway (not to mention all those MX and IP address domain queries), so why
not just keep sending data packets so you can pick up where things left off?
Only when the remote host crashes and comes back up will you have to start
over.  The only drawback I can see with this is the memory used by the
almost idle mailer, but hey, memory is free these days.

So the solution, I think, is to use ICMP messages for debugging, but don't
let them affect TCP's actions.  One of my pet peeves about many TCP
implementations is how impatient they are, both in retransmission timing and
"give up" timing.  The end result is a network prone to the kind of
congestion collapse John Nagle talked about in his paper on networks with
infinite buffering.  Fix the timers and you'll avoid this.

Phil

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Feb-87 18:32:19 EST
From:      MQH@CORNELLC.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Telnet Option Negotiation to IBMish Hosts

Hello (and forgive me, this is awful long),
 
I'm trying to decide how to "correctly" implement TELNET option
negotiation for programs which can emulate both ASCII and EBCDIC.
I support Wiscnet (a VM implementation of TCP/IP) here at Cornell.
I've been working with one of our programmers who's been working on
Cornell versions of TN3270 which run on MACs and PCs.  Our TN3270s
can successfully negotiate into 3270 terminal emulation with Wiscnet,
but we've discovered that they can't talk to KNET (yet another
implementation of TCP/IP for VM).  It turns out that Wiscnet can't
talk to KNET either, and that Berkeley's latest release of TN3270
doesn't talk to KNET in 3270 mode.
 
I've spent some time researching this whole mess, and my results
are below (I'm of the opinion that everyone's at least a little
busted).  Basically, the big problem is how to decide that we're
going to do the connection in EBCDIC.  I don't think the current
RFCs for telnet supply enough information on how to properly handle
EBCDIC connections.
 
Here is a basic summary of the various "philosophies" of option
negotiation in the code I've dealt with.  I'll warn you in advance
that these are my impressions, and best guesses, and that I've been
known to be wrong.  If I am wrong, please let me know.
 
Wiscnet
   After establishment of the connection, both user, and server must
   "discuss" the following options, IN THIS ORDER, to form a
   "transparent mode" (3270) connection.  TERMINAL TYPE, END OF RECORD,
   TRANSMIT BINARY.  If any of the options are settled out of order,
   or some of the responses are unacceptable, or data arrives before
   option negotiation completes, the connection will irrevocably be
   put into "line mode" (ASCII).
 
KNET
   After establishment of the connection, KNET will send a one line
   blurb in ASCII announcing itself and the host.  Then option
   negotiation begins.  If KNET does a SEND TERMINAL TYPE, and the
   user code responds with a valid 3270-ish terminal, KNET sends
   DO BINARY, WILL BINARY, and begins sending EBCDIC data.
   If it doesn't get an acceptable terminal type, the server puts
   up a menu of ASCII terminals it's willing to do protocol conversion
   for.
 
Cornell TN3270 (PC and MAC)
   Always responds to SEND TERMINAL TYPE with "IBM-3278-2".
   Hack 1:
      If the server sends DO EOR, we enter 3270 emulation mode.
      If not, we do H19 emulation.
   Hack 2:
      If the server sends DO BINARY, we enter 3270 emulation mode.
      If not, we do H19 emulation.
 
Berkeley TN3270 (UN*X hosts) (I'm not at all positive about this one)
   Always responds to SEND TERMINAL TYPE with "IBM-3278-2".
   If we change an option, and we get to a state where we
   have sent IBM-3278-2, and we are sending and receiving
   in binary, we enter 3270 emulation.
 
Now, after all that, we can look at why some won't talk to others.
 
Wiscnet -> KNET
   When the KNET server sends its one line blurb, Wiscnet decides
   to do line mode emulation.  Unfortunately, it will still respond
   with options appropriate to 3270 emulation.  The result is that
   KNET server is in 3270 mode, and Wiscnet user code is in ASCII
   line mode.  I'm not sure of how the reverse case turns out.
 
Cornell TN3270 -> KNET
   KNET doesn't initiate EOR option processing with the user.
   Hack 1 of our TN3270 therefore never went into 3278 emulation.
   Hack 2 does better, but we've come upon a bug at the TCP level.
   We're looking into it.
 
Berkeley TN3270 -> KNET
   An old release (March 22, 1985) works fine.  A newer release,
   (January 11, 1986) end's up talking to KNET in ASCII, and is
   forced to use the KNET protocol conversion.  I think it's
   KNET's fault.  The new TN3270 does a DO SUPPRESS GO AHEAD
   before KNET gets a chance to send an option.  I think this
   confuses KNET, because it never gets around to sending a
   SEND TERMINAL TYPE.  Since it never gets a 3270-ish terminal
   type from the user, it does ASCII emulation.  Fortunately,
   since TN3270 never sent it's terminal type, it also decides
   to do ASCII.
 
 
Now that that's clear as mud....
 
It seems that most all the implementations seem to think that the
BINARY option is the way to do EBCDIC.  Is that cool?  It seems to me
that an "EBCDIC" option would be less confusing.  I DON'T think that
the ASCII/EBCDIC question should be settled based on terminal type
'cause most UN*X implementations won't behave properly.  If the
server doesn't know how to do the terminal type announced by the
user code, it's supposed to ask the user if it'll do something else.
In practice, I haven't seen a single implementation that does this.
Berkeley 4.2 never asked, and Berkeley 4.3 asks only once.  It doesn't
notice, for example, that "IBM-3278-2" isn't in its termcap.
 
So, I guess I'd like to see an EBCDIC option added to telnet.  Once
that's in place, it's a trivial matter to make one end or the other
announce that it WILL EBCDIC.  If both sides DO EBCDIC, then
everything would be fine.  The matter of 3270 emulation could be
decided with TERMINAL TYPE negotiation.  If EBCDIC is refused, then
both ends would do the connection in ASCII.
 
If an EBCDIC option is the way to go, I have two questions.  First,
would the server, or the user announce WILL EBCDIC?  The TN3270
programs are a little wierd in that they can emulate more than
one kind of terminal.  Second, would EBCDIC imply anything about
BINARY?
 
My thanks in advance for any comments you have on the subject.
I hope that we can come to a quick resolution to this problem so
we can get all our IBM implementations talking to one another.
 
Mike Hojnowski
Long-winded Wiscnet Grunt
Cornell Theory Center

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Feb 87 18:32:19 EST
From:      Mike Hojnowski <MQH%CORNELLC.BITNET@wiscvm.wisc.edu>
To:        TCP-IP Newsgroup <tcp-ip@sri-nic.arpa>, Wiscnet Interested Party List <WISCNET@TCSVM>, KNET Interested Party List <KNET-L@TAMVM1>
Subject:   Telnet Option Negotiation to IBMish Hosts
Hello (and forgive me, this is awful long),
 
I'm trying to decide how to "correctly" implement TELNET option
negotiation for programs which can emulate both ASCII and EBCDIC.
I support Wiscnet (a VM implementation of TCP/IP) here at Cornell.
I've been working with one of our programmers who's been working on
Cornell versions of TN3270 which run on MACs and PCs.  Our TN3270s
can successfully negotiate into 3270 terminal emulation with Wiscnet,
but we've discovered that they can't talk to KNET (yet another
implementation of TCP/IP for VM).  It turns out that Wiscnet can't
talk to KNET either, and that Berkeley's latest release of TN3270
doesn't talk to KNET in 3270 mode.
 
I've spent some time researching this whole mess, and my results
are below (I'm of the opinion that everyone's at least a little
busted).  Basically, the big problem is how to decide that we're
going to do the connection in EBCDIC.  I don't think the current
RFCs for telnet supply enough information on how to properly handle
EBCDIC connections.
 
Here is a basic summary of the various "philosophies" of option
negotiation in the code I've dealt with.  I'll warn you in advance
that these are my impressions, and best guesses, and that I've been
known to be wrong.  If I am wrong, please let me know.
 
Wiscnet
   After establishment of the connection, both user, and server must
   "discuss" the following options, IN THIS ORDER, to form a
   "transparent mode" (3270) connection.  TERMINAL TYPE, END OF RECORD,
   TRANSMIT BINARY.  If any of the options are settled out of order,
   or some of the responses are unacceptable, or data arrives before
   option negotiation completes, the connection will irrevocably be
   put into "line mode" (ASCII).
 
KNET
   After establishment of the connection, KNET will send a one line
   blurb in ASCII announcing itself and the host.  Then option
   negotiation begins.  If KNET does a SEND TERMINAL TYPE, and the
   user code responds with a valid 3270-ish terminal, KNET sends
   DO BINARY, WILL BINARY, and begins sending EBCDIC data.
   If it doesn't get an acceptable terminal type, the server puts
   up a menu of ASCII terminals it's willing to do protocol conversion
   for.
 
Cornell TN3270 (PC and MAC)
   Always responds to SEND TERMINAL TYPE with "IBM-3278-2".
   Hack 1:
      If the server sends DO EOR, we enter 3270 emulation mode.
      If not, we do H19 emulation.
   Hack 2:
      If the server sends DO BINARY, we enter 3270 emulation mode.
      If not, we do H19 emulation.
 
Berkeley TN3270 (UN*X hosts) (I'm not at all positive about this one)
   Always responds to SEND TERMINAL TYPE with "IBM-3278-2".
   If we change an option, and we get to a state where we
   have sent IBM-3278-2, and we are sending and receiving
   in binary, we enter 3270 emulation.
 
Now, after all that, we can look at why some won't talk to others.
 
Wiscnet -> KNET
   When the KNET server sends its one line blurb, Wiscnet decides
   to do line mode emulation.  Unfortunately, it will still respond
   with options appropriate to 3270 emulation.  The result is that
   KNET server is in 3270 mode, and Wiscnet user code is in ASCII
   line mode.  I'm not sure of how the reverse case turns out.
 
Cornell TN3270 -> KNET
   KNET doesn't initiate EOR option processing with the user.
   Hack 1 of our TN3270 therefore never went into 3278 emulation.
   Hack 2 does better, but we've come upon a bug at the TCP level.
   We're looking into it.
 
Berkeley TN3270 -> KNET
   An old release (March 22, 1985) works fine.  A newer release,
   (January 11, 1986) end's up talking to KNET in ASCII, and is
   forced to use the KNET protocol conversion.  I think it's
   KNET's fault.  The new TN3270 does a DO SUPPRESS GO AHEAD
   before KNET gets a chance to send an option.  I think this
   confuses KNET, because it never gets around to sending a
   SEND TERMINAL TYPE.  Since it never gets a 3270-ish terminal
   type from the user, it does ASCII emulation.  Fortunately,
   since TN3270 never sent it's terminal type, it also decides
   to do ASCII.
 
 
Now that that's clear as mud....
 
It seems that most all the implementations seem to think that the
BINARY option is the way to do EBCDIC.  Is that cool?  It seems to me
that an "EBCDIC" option would be less confusing.  I DON'T think that
the ASCII/EBCDIC question should be settled based on terminal type
'cause most UN*X implementations won't behave properly.  If the
server doesn't know how to do the terminal type announced by the
user code, it's supposed to ask the user if it'll do something else.
In practice, I haven't seen a single implementation that does this.
Berkeley 4.2 never asked, and Berkeley 4.3 asks only once.  It doesn't
notice, for example, that "IBM-3278-2" isn't in its termcap.
 
So, I guess I'd like to see an EBCDIC option added to telnet.  Once
that's in place, it's a trivial matter to make one end or the other
announce that it WILL EBCDIC.  If both sides DO EBCDIC, then
everything would be fine.  The matter of 3270 emulation could be
decided with TERMINAL TYPE negotiation.  If EBCDIC is refused, then
both ends would do the connection in ASCII.
 
If an EBCDIC option is the way to go, I have two questions.  First,
would the server, or the user announce WILL EBCDIC?  The TN3270
programs are a little wierd in that they can emulate more than
one kind of terminal.  Second, would EBCDIC imply anything about
BINARY?
 
My thanks in advance for any comments you have on the subject.
I hope that we can come to a quick resolution to this problem so
we can get all our IBM implementations talking to one another.
 
Mike Hojnowski
Long-winded Wiscnet Grunt
Cornell Theory Center
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Feb-87 21:55:47 EST
From:      gnu@cgl.ucsf.edu@hoptoad.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Telnet 8th bit: a good use for that bit...

JBVB%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU ("James B. VanBokkelen") writes:
> A couple of weeks ago, I posted a query about Telnet implementations
> that sent Ascii with bit 8 set (parity, or whatever).  The question
> was brought on when I ran across code that religiously masked off
> the high bit before passing it to a PC's display.

I think that it would be good to specify that 8-bit values passed
on Telnet connections are in ISO Latin I (essentially, extend NETASCII
to 8 bits using the ISO character set that contains all the graphics
for all the Latin languages).

If the number of programs that actually pass 8-bit data is small enough
(James' list only showed about 5 programs) then this change can be feasible.

Note that since SMTP uses telnet encoding, this would allow international
characters in mail, entered in a local character set, translated to ISO 
Latin I while flying over the wire, then translated to the recipient's local
character set.

This would have implications for FTP, too, if it was adopted.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1987 10:44-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        MQH%CORNELLC.BITNET@WISCVM.WISC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:      Telnet Option Negotiation to IBMish Hosts
Right  off the bat, EBCDIC would imply BINARY.  Correct me if I'm
wrong, my brush with OBM EBCDIC was about 6 years ago, but EBCDIC
is  a  8-bit  code,  nd  the  very  codes  TELNET  uses to do the
negotiations are probably shadowed by EBCDIC characters.  If  you
want  to still have a TELNET character capability, you'll have to
define what  EBCDIC  characters  represent  what  TELNET  special
characters.

Mike
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Feb-87 18:39:53 EST
From:      malis@CC5.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Congestion

Mike,

Just so you (and the rest of list) know, the patch that fixes the
HDH problem was installed on the ARPANET yesterday (Friday)
afternoon.  It had previously been installed on the MILNET
(because two hosts had encountered this problem), and was
awaiting DDN approval for the ARPANET installation.

Regards,
Andy

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 87 18:39:53 EST (Sat)
From:      Andy Malis <malis@cc5.bbn.com>
To:        STJOHNS@sri-nic.ARPA
Cc:        nowicki@sun.com, tcp-ip@sri-nic.ARPA, malis@cc5.bbn.com
Subject:   Re: Congestion
Mike,

Just so you (and the rest of list) know, the patch that fixes the
HDH problem was installed on the ARPANET yesterday (Friday)
afternoon.  It had previously been installed on the MILNET
(because two hosts had encountered this problem), and was
awaiting DDN approval for the ARPANET installation.

Regards,
Andy
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Feb-87 01:17:36 EST
From:      news@seismo.CSS.GOV@sun.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Telnet 8th bit: a good use for that bit...
Message-ID: <13334@sun.uucp>
Date: 15 Feb 87 06:17:35 GMT
References: <969432.870211.JBVB@MX.LCS.MIT.EDU> <8702140255.AA14335@hoptoad.uucp>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 11

>I think that it would be good to specify that 8-bit values passed
>on Telnet connections are in ISO Latin I (essentially, extend NETASCII
>to 8 bits using the ISO character set that contains all the graphics
>for all the Latin languages).

That would leave all the non-Latin languages, like Japanese, Chinese,
Korean, etc., out in the cold.  It would be a mistake to require that
8-bit values (i.e, GR characters, with the 8th bit set) passed over
TELNET connections be in one particular character set.  If need be,
there could be TELNET options to indicate which character set is
being sent over the wire.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Feb-87 14:25:30 EST
From:      km@EMORY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Ethernet Security

How difficult is it to do ethernet address impersonation without
hardware (including eprom) modification in commonly available
workstations? For example, we have: Sun 3's, Microvaxen, 3B2s,
3B1's, and IBM PCs with 3-COM cards. On which of these could
the Super user (or any user on the PC), alter his ethernet address
in software without taking the box apart?

I realize this is one tiny aspect of security, but it is one our
administration has seized upon. It turns out our departmental
ethernets are linked with filtered bridges, which have a naive
filtering criteria. If they have ever seen an ethernet packet with
a given source address on an ethernet, they will from then on
pass all packets with that destination address accross the
bridge to that ethernet. 

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Feb-87 15:37:48 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Submission for mod-protocols-tcp-ip


     I don't know what is done with Chinese or Korean, but Japanese
uses a 14-bit character set, using only the values 21h-7Eh (that's
041 to 176 for us octal fans); that is, those values in 7-bit ASCII
that represent printing characters.  An ESCAPE sequence shifts between
ASCII and JIS (Japanese Industrial Standard).

     An alternate means supports katakana only, using either the
eighth bit or ASCII shift codes (SO/SI, a.k.a. CTRL/N and CTRL/O).
Some terminals support both systems; however, the katakana-only
system is obsolete today.

     One must recognize that 8 bits are never enough!  It is perfectly
alright to assign an 8-bit system for your local use, but it is pure
egotism to believe that your 8-bit system is somehow superior to
anyone else's and therefore should be adopted as a standard.  Really,
the eighth bit is best left for parity or undefined for a local
application.  To represent international characters, you need a
larger character set.

     If a vote were taken today, I would vote for JIS.  I believe that
as long as your terminal supports overstriking you can get all the
silly ISO characters using JIS.  In addition, you also get Greek and
Russian.  I'm not sure about Chinese, but JIS includes several thousand
Chinese characters (kanji), most of which aren't generally used in
Japanese.
-------

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Feb-87 22:00:06 EST
From:      mark@cbosgd.mis.oh.att.com.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Telnet 8th bit: a good use for that bit...

>>I think that it would be good to specify that 8-bit values passed
>>on Telnet connections are in ISO Latin I (essentially, extend NETASCII
>>to 8 bits using the ISO character set that contains all the graphics
>>for all the Latin languages).
>
>That would leave all the non-Latin languages, like Japanese, Chinese,
>Korean, etc., out in the cold.  It would be a mistake to require that
>8-bit values (i.e, GR characters, with the 8th bit set) passed over
>TELNET connections be in one particular character set.  If need be,
>there could be TELNET options to indicate which character set is
>being sent over the wire.

Good point.

The Japanese standard (or at least one of them) is in some sense upward
compatible with ASCII and European character sets.  Two byte sequences
with both high order bits set are Kanji, single bytes with the high
bit set are European.  Anything that might be a control character is
always a control char, no matter what else surrounds it.

I don't have the details, and I don't know if this extends to Korean.
I know it won't handle Chinese, because there are more characters in
the Chinese language.

However, TELNET option negotiation is very good at this sort of thing,
all we'd have to do is standardize the character sets (or provide an
open ended option that can be grown as needed.)

I suspect that if we just say that TELNET has to be 8 bit transparent
(except for a couple of things like 377 and CR) then most of the rest
of this won't matter - we could apply a default character set (which
might be ASCII, or European) unless options are negotiated otherwise.

	Mark

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Feb-87 22:42:00 EST
From:      BEAME@MCMASTER.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   re:Ethernet Security

> How easy is it to impersinate another ethernet address on a ...
 
On an IBM-PC with 3-Com card, all one has to do to impersonate an ethernet
address is to output the desired address to an I/O port on the card and you
have become that address.
 
If you have Micro-Vaxen running VMS and NO other network activity is being
used such as DECNET, then with privilege you can become any ethernet address.
 
I wanted to say the following when the "security messages" were flying, but
I just didn't get around to it.
 
Well here goes : The only method of making ethernet "Semi-secure" is to encrypt
the data packets. But the question of what method of encryption is
appropriate and feasable seems to bog down the incorporation of encryption
into protcols like TCP/IP.
 
 Why can't a range of encryption methods be used, from XOR's to DES, and
make an IP option which indicates the "highest level" that an
implementation supports. The option also could be used to indicate the desired
security level and the level that is obtainable with the current connection.
 
 This way PC/IP's can implement low level encryption and still be
compatible with more sophisticated implementions.
 
Carl Beame
BEAME@MCMASTER.BITNET
 
 

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Feb 87 22:42 EST
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   re:Ethernet Security
> How easy is it to impersinate another ethernet address on a ...
 
On an IBM-PC with 3-Com card, all one has to do to impersonate an ethernet
address is to output the desired address to an I/O port on the card and you
have become that address.
 
If you have Micro-Vaxen running VMS and NO other network activity is being
used such as DECNET, then with privilege you can become any ethernet address.
 
I wanted to say the following when the "security messages" were flying, but
I just didn't get around to it.
 
Well here goes : The only method of making ethernet "Semi-secure" is to encrypt
the data packets. But the question of what method of encryption is
appropriate and feasable seems to bog down the incorporation of encryption
into protcols like TCP/IP.
 
 Why can't a range of encryption methods be used, from XOR's to DES, and
make an IP option which indicates the "highest level" that an
implementation supports. The option also could be used to indicate the desired
security level and the level that is obtainable with the current connection.
 
 This way PC/IP's can implement low level encryption and still be
compatible with more sophisticated implementions.
 
Carl Beame
BEAME@MCMASTER.BITNET
 
 
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Feb-87 03:42:49 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   TELNET and national language support

As long as everyone is talking about national language support:
 
We in Israel have a number of problems with TELNET.  IBM started out about
18 years ago and came out with a Hebrew code that mapped right on top of all
lowercase characters in the EBCDIC character set.  That was fairly short
sighted on IBM's part and recently they came out with something known as
newcode - which maps the 27 hebrew characters to x'41'-x'49', x'51'-x'59',
x'62'-x'69', and x'71'.  Two years ago they came out with something known
as bulletin code which moves some things around again.  To make matters
worse - other computer manufacturers have their own standard - and even the
IBM PC has a different standard in ASCII.
 
On top of that we have the problem of typing right to left rather than
left to right.  Compounding the problem is mixed language documents (English -
Hebrew) and even if you ignore that problem you still have the problem of
entering numbers in a Hebrew document.  There are various terminal
implementations that try to resolve this problem but none have been tested
in a TELNET type environment.
 
One day we will have cross that bridge.
 
Hank

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Feb-87 08:44:00 EST
From:      NS-DDN@DDN2.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   SMTP Uses TELNET ?



From RFC 821, Section 4.5.5. Transparency:
 
  The mail data may contain any of the 128 ASCII characters. All characters
  are to be delivered to the recipient's mailbox including format effectors
  and other control characters. If the transmission channel provides an 8-bit
  byte (octets) data stream, the 7-bit ASCII codes are transmitted right
  justified in the octets with the high order bits cleared to zero.
 
and again, in Appendix A, under Data Transfer:
 
  The TCP connection supports the transmission of 8-bit bytes. The SMTP data
  is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte
  with the high-order bit cleared to zero.
 
Please, let's not clutter up the TCP-IP SIG with gross inaccuracies. The
archive should be a repository of wheat, not chaff.
 
Dave Craig
Network Solutions, Inc.

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 87 08:44 EST
From:      NS-DDN @ DDN2
To:        tcp-ip @ SRI-NIC.ARPA
Subject:   SMTP Uses TELNET ?


From RFC 821, Section 4.5.5. Transparency:
 
  The mail data may contain any of the 128 ASCII characters. All characters
  are to be delivered to the recipient's mailbox including format effectors
  and other control characters. If the transmission channel provides an 8-bit
  byte (octets) data stream, the 7-bit ASCII codes are transmitted right
  justified in the octets with the high order bits cleared to zero.
 
and again, in Appendix A, under Data Transfer:
 
  The TCP connection supports the transmission of 8-bit bytes. The SMTP data
  is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte
  with the high-order bit cleared to zero.
 
Please, let's not clutter up the TCP-IP SIG with gross inaccuracies. The
archive should be a repository of wheat, not chaff.
 
Dave Craig
Network Solutions, Inc.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Feb 87 11:57:11 PST
From:      John B. Nagle <jbn@glacier.stanford.edu>
To:        TCP-IP@nic.sri.com
Subject:   Retrying after Destination Unreachable
     If implementors want to regard ICMP Destination Unreachable as
non-fatal in TCP, hoping that things will get better, they should
at least crank up the retransmit timer and slam the congestion window
when it happens, since if things are so bad that one is getting
ICMP Destination Unreachable, one should at least back off.  One
could think of Destination Unreachable as a very strong Source Quench.

					John Nagle
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Feb-87 14:34:22 EST
From:      guy@SUN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Telnet 8th bit: a good use for that bit...

> The Japanese standard (or at least one of them) is in some sense upward
> compatible with ASCII and European character sets.  Two byte sequences
> with both high order bits set are Kanji, single bytes with the high
> bit set are European.  Anything that might be a control character is
> always a control char, no matter what else surrounds it.

One of them - the UJIS code, as proposed by AT&T - is definitely
*not* compatible in this fashion; any byte with the 8th bit on,
unless preceded by an SS2, is either the first or second byte of a
two-byte Kanji (or Gaiji, but making *that* work would require TELNET
options to send fonts!) character.  Does the other one - Shift-JIS -
avoid all of the code points used by ISO Latin 1?  The UJIS code is
specified by the Sigma Project, and is being adopted by a number of
UNIX systems, at least, in Japan.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Feb-87 14:57:11 EST
From:      jbn@GLACIER.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Retrying after Destination Unreachable


     If implementors want to regard ICMP Destination Unreachable as
non-fatal in TCP, hoping that things will get better, they should
at least crank up the retransmit timer and slam the congestion window
when it happens, since if things are so bad that one is getting
ICMP Destination Unreachable, one should at least back off.  One
could think of Destination Unreachable as a very strong Source Quench.

					John Nagle

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Feb 87 17:58 PST
From:      Kevin Carosso <KVC@ENGVAX.UUCP>
To:        tcp-ip@sri-nic.ARPA
Subject:   Problem with TCP state transitions in CLOSE
I'm having a problem with an implementation detail of a TCP/IP and I hope
I can get some insights from those who've gone before.
 
The situation is as follows:
 
According to RFC 793, a CLOSE operation means "I have no more data to send."
"The user who CLOSEs may continue to RECEIVE until he is told that the
other side has CLOSED also."
 
Now, my client application does a CLOSE, the TCP sends a FIN and goes from
ESTABLISHED to FIN-WAIT-1.  When the FIN is ACKed, it goes from FIN-WAIT-1
to FIN-WAIT-2.  While in FIN-WAIT-1 or FIN-WAIT-2, data continues to be
received from the network and the application may continue to issue RECEIVEs
to get the data.  Finally, the other end of the connection does a CLOSE
and the TCP receives a FIN.  Receiving a FIN in FIN-WAIT-2 means transition
to TIME-WAIT.
 
The TCP receives a data segment while in FIN-WAIT-2, just before receiving
the FIN.  Now, it's entirely likely that the application won't get around to
doing it's next RECEIVE (for what will be the last buffer of data sent over
from it's buddy on the other end) until the TCP has gotten the FIN.
(Not only is this likely, it happens most of the time, depending on
system response time, to an application here.)
 
The question is, what is a TCP to do if it is in FIN-WAIT-2, it has some
user data that the user hasn't asked for yet, and a FIN comes in?  If it
goes immediately to TIME-WAIT (as this TCP does) the user will receive an error
because RFC 793 says that a RECEIVE call while in TIME-WAIT returns "error:
connection closing."  Seems to me that what we would like to be in here
is a state similar to CLOSE-WAIT, in that RECEIVEs are allowed, but "must
be satisfied by text already on hand, but not yet delivered to the user."
 
There are two possible work-arounds that I came up with, though I am not
particularly happy with them and will wait for some cogent feedback before
implementing.
 
1) Go to TIME-WAIT as the spec says, but handle a user RECEIVE call as described
   in CLOSE-WAIT.
2) If there is user data outstanding when you get a FIN in FIN-WAIT-2, delay
   the transition to TIME-WAIT until the user data has been delivered to
   the user (i.e. he came and asked for it all).
 
My problems with 1) are that you aren't really following what the spec says
and that I'm not sure what to do if that user data is still there after
the 2 MSL timeout has passed.  I don't think it's right for the data to
go away after 2 MSL, since then the success  of the application is dependent
on how fast it can RECEIVE, and I don't think the TCP is supposed to introduce
restrictions like that.  (Please tell me if I'm off base here!)
 
Maybe 2) is better?  Seems to me, though, that the state transition isn't
really handled as the spec says. Also, are you getting out of synch by
staying in FIN-WAIT-2 when everyone expects you to have moved onto TIME-WAIT?
If so, does anyone care?
 
Why did RFC 793 specifically describe what to do with user data in CLOSE-WAIT
but not in this case?
 
How have others handled this in their implementations?  I tried to look
through the Berkeley 4.3 code, but found it a little murky.  I decided they
didn't do (2) but am not sure exactly what voodoo they do do.
 
Thanks for any info,
 
        /Kevin Carosso              kvc%engvax.uucp@usc-oberon.usc.edu
         Hughes Aircraft Co.
 
ps.  If anyone cares, it's the CMU rewrite of the Tektronix IP/TCP code
     for VAX/VMS.
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Feb 1987 10:42:49 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   TELNET and national language support
As long as everyone is talking about national language support:
 
We in Israel have a number of problems with TELNET.  IBM started out about
18 years ago and came out with a Hebrew code that mapped right on top of all
lowercase characters in the EBCDIC character set.  That was fairly short
sighted on IBM's part and recently they came out with something known as
newcode - which maps the 27 hebrew characters to x'41'-x'49', x'51'-x'59',
x'62'-x'69', and x'71'.  Two years ago they came out with something known
as bulletin code which moves some things around again.  To make matters
worse - other computer manufacturers have their own standard - and even the
IBM PC has a different standard in ASCII.
 
On top of that we have the problem of typing right to left rather than
left to right.  Compounding the problem is mixed language documents (English -
Hebrew) and even if you ignore that problem you still have the problem of
entering numbers in a Hebrew document.  There are various terminal
implementations that try to resolve this problem but none have been tested
in a TELNET type environment.
 
One day we will have cross that bridge.
 
Hank
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Feb-87 20:58:00 EST
From:      KVC@ENGVAX.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Problem with TCP state transitions in CLOSE

I'm having a problem with an implementation detail of a TCP/IP and I hope
I can get some insights from those who've gone before.
 
The situation is as follows:
 
According to RFC 793, a CLOSE operation means "I have no more data to send."
"The user who CLOSEs may continue to RECEIVE until he is told that the
other side has CLOSED also."
 
Now, my client application does a CLOSE, the TCP sends a FIN and goes from
ESTABLISHED to FIN-WAIT-1.  When the FIN is ACKed, it goes from FIN-WAIT-1
to FIN-WAIT-2.  While in FIN-WAIT-1 or FIN-WAIT-2, data continues to be
received from the network and the application may continue to issue RECEIVEs
to get the data.  Finally, the other end of the connection does a CLOSE
and the TCP receives a FIN.  Receiving a FIN in FIN-WAIT-2 means transition
to TIME-WAIT.
 
The TCP receives a data segment while in FIN-WAIT-2, just before receiving
the FIN.  Now, it's entirely likely that the application won't get around to
doing it's next RECEIVE (for what will be the last buffer of data sent over
from it's buddy on the other end) until the TCP has gotten the FIN.
(Not only is this likely, it happens most of the time, depending on
system response time, to an application here.)
 
The question is, what is a TCP to do if it is in FIN-WAIT-2, it has some
user data that the user hasn't asked for yet, and a FIN comes in?  If it
goes immediately to TIME-WAIT (as this TCP does) the user will receive an error
because RFC 793 says that a RECEIVE call while in TIME-WAIT returns "error:
connection closing."  Seems to me that what we would like to be in here
is a state similar to CLOSE-WAIT, in that RECEIVEs are allowed, but "must
be satisfied by text already on hand, but not yet delivered to the user."
 
There are two possible work-arounds that I came up with, though I am not
particularly happy with them and will wait for some cogent feedback before
implementing.
 
1) Go to TIME-WAIT as the spec says, but handle a user RECEIVE call as described
   in CLOSE-WAIT.
2) If there is user data outstanding when you get a FIN in FIN-WAIT-2, delay
   the transition to TIME-WAIT until the user data has been delivered to
   the user (i.e. he came and asked for it all).
 
My problems with 1) are that you aren't really following what the spec says
and that I'm not sure what to do if that user data is still there after
the 2 MSL timeout has passed.  I don't think it's right for the data to
go away after 2 MSL, since then the success  of the application is dependent
on how fast it can RECEIVE, and I don't think the TCP is supposed to introduce
restrictions like that.  (Please tell me if I'm off base here!)
 
Maybe 2) is better?  Seems to me, though, that the state transition isn't
really handled as the spec says. Also, are you getting out of synch by
staying in FIN-WAIT-2 when everyone expects you to have moved onto TIME-WAIT?
If so, does anyone care?
 
Why did RFC 793 specifically describe what to do with user data in CLOSE-WAIT
but not in this case?
 
How have others handled this in their implementations?  I tried to look
through the Berkeley 4.3 code, but found it a little murky.  I decided they
didn't do (2) but am not sure exactly what voodoo they do do.
 
Thanks for any info,
 
        /Kevin Carosso              kvc%engvax.uucp@usc-oberon.usc.edu
         Hughes Aircraft Co.
 
ps.  If anyone cares, it's the CMU rewrite of the Tektronix IP/TCP code
     for VAX/VMS.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      16 FEB 87 21:25-EST
From:      WITLICKI%WILLIAMS.BITNET@wiscvm.wisc.edu
To:        TCP-IP @ SRI-NIC.ARPA
Subject:   Ethernet Security
>From:         Ken Mandelberg <KM@EMORY.ARPA>
>Subject:      Ethernet Security
>
> How difficult is it to do ethernet address impersonation without
> hardware (including eprom) modification in commonly available
>workstations? For example, we have: Sun 3's, Microvaxen, 3B2s,
>3B1's, and IBM PCs with 3-COM cards. On which of these could...
>
>I realize this is one tiny aspect of security, but it is one our
>administration has seized upon. It turns out our departmental
>ethernets are linked with filtered bridges, which have a naive...
 
   Hardware ethernet addresses and university administrative worries
are almost two separate issues.
   Perhaps M. Padlipsky can fill us in on the finer points of layering
manners here..
   The hardware (rom) says Boot Me Now, please...
   If I don't need to be booted off of your file server I may not
need a special hardware address.
   Up a few layers you have Mail From:  things flying around...
   The filtering bridges are almost irrelevant.
   I can break into the wiring closet where the college president's
phone line is, I may tap into the comm. link for your IBM mainframe
which probably doesn't have link level encryption... but that takes
involved intent and effort;   I think you are asking - what about
the hacker in a lab with a PC with an ethernet card?
   Keep the academic (students) stuff *physically* separate from
your sensitive data (i.e. administrative systems)
 
- randy
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Feb-87 21:32:04 EST
From:      WITLICKI@WILLIAMS.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Ethernet Security

>From:         Ken Mandelberg <KM@EMORY.ARPA>
>Subject:      Ethernet Security
>
> How difficult is it to do ethernet address impersonation without
> hardware (including eprom) modification in commonly available
>workstations? For example, we have: Sun 3's, Microvaxen, 3B2s,
>3B1's, and IBM PCs with 3-COM cards. On which of these could...
>
>I realize this is one tiny aspect of security, but it is one our
>administration has seized upon. It turns out our departmental
>ethernets are linked with filtered bridges, which have a naive...
 
   Hardware ethernet addresses and university administrative worries
are almost two separate issues.
   Perhaps M. Padlipsky can fill us in on the finer points of layering
manners here..
   The hardware (rom) says Boot Me Now, please...
   If I don't need to be booted off of your file server I may not
need a special hardware address.
   Up a few layers you have Mail From:  things flying around...
   The filtering bridges are almost irrelevant.
   I can break into the wiring closet where the college president's
phone line is, I may tap into the comm. link for your IBM mainframe
which probably doesn't have link level encryption... but that takes
involved intent and effort;   I think you are asking - what about
the hacker in a lab with a PC with an ethernet card?
   Keep the academic (students) stuff *physically* separate from
your sensitive data (i.e. administrative systems)
 
- randy

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Feb-87 03:07:53 EST
From:      kik@CERNVAX.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: cernvax!kik
From: kik@cernvax.UUCP (kik)
Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans
Subject: IEEE/Blue Book problem and MAC-level bridges
Message-ID: <439@cernvax.UUCP>
Date: 17 Feb 87 08:07:52 GMT
References: <12277078297.16.ROMKEY@XX.LCS.MIT.EDU>
Reply-To: kik@cernvax.UUCP ()
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw
Lines: 33
 
    The discussion on MAC-level bridging seems to have concentrated so  far
on  the  difference  between  the Ethernet 2.0 and IEEE 802.3 formats (i.e.
Type/length field).  What seems considerably more worrying is  the  problem
raised  by  the  IBM  insistence  for the acceptance by the standardisation
bodies of their "source-level routing" for Token Ring (TR).
 
   For those of you in the happy state of ignorance about this approach, it
works  as  follows:  for  an unknown MAC-level address, an enquiry frame is
broadcast through all TR-bridges,  which  add  their  own  address  to  the
recorded  route.  The  bridge  on the ring that carries the desired address
returns the  enquiry  (with  the  recorded  route)  to  the  enquirer.  All
subsequent  frames  to this address then carry this routing (ISO level 3!!)
information directly after the destination and source address fields  (i.e.
before  the  LLC).  In  addition,  to  indicate  that  source routing is in
action, the source address has the "casting" bit (least significant of most
significant byte) set.
 
     One can imagine the excitement that this sort of frame will  cause  if
it  appears  via a (normal) bridge on an Ethernet segment.  Even if the IBM
pollution is purged by an intelligent bridge,  the  reverse  path  for  the
response  is  somewhat  problematical,  and  would entail maintaining a "TR
routing table" in the bridge.
 
     It is clear that the IBM approach is (to say the least) not  optimised
for  a  connectionless environment.  What is not clear, however, is whether
it has *any* advantages over a true MAC-level bridge.
 
     I would be grateful for clarification from people who understand  both
approaches more cpmpletely than I.
 
                      Crispin (KIK) Piney
 
CERN, Geneva, Switzerland

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1987 11:40-EST
From:      CLYNN@G.BBN.COM
To:        kvc%engvax.uucp@USC-OBERON.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Problem with TCP state transitions in CLOSE
Kevin,

>   The question is, what is a TCP to do if it is in FIN-WAIT-2, it has
>   some user data that the user hasn't asked for yet, and a FIN comes in?

Remember that SYN and FIN are controls which occupy sequence space.
Arriving segments are "generally queued and processed in sequence
number order" (section 3.9).  Later in the section: "segment arrives",
"Otherwise", "seventh, process the segment text", requires that the
data be processed (given to the user) before one is allowed to get to
"eighth, check the fin bit".

Your solution 2
>  2) If there is user data outstanding when you get a FIN in FIN-WAIT-2,
>     delay the transition to TIME-WAIT until the user data has been
>     delivered to the user (i.e. he came and asked for it all).
has the proper effect, but the sequence number restrictions mean you
technically cannot "get a FIN" "until the user data has been delivered
to the user."

Charlie
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Feb-87 12:55:33 EST
From:      geof@decwrl.DEC.COM@apolling.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Problem with TCP state transitions in CLOSE


 > The TCP receives a data segment while in FIN-WAIT-2, just before receiving
 > the FIN.  Now, it's entirely likely that the application won't get around to
 > doing it's next RECEIVE (for what will be the last buffer of data sent over
 > from it's buddy on the other end) until the TCP has gotten the FIN.

The SYN & FIN bits are bytes of control that are IN the data stream.
They consume sequence numbers, and only have meaning when taken in
sequence.  The presence of a FIN at the TCP level may cause a state
to be changed or a flag to be set, but the connection can not actually
close until the application has tried to RECEIVE the FIN.

Thus, there are two aspects of TCP state, the state at the TCP level,
and the state as transmitted by TCP to its client level.  The TCP
connection transitions to TIME-WAIT when it receives a FIN that is
ready to be delivered to the client (note that last caveat, if the
last data packet was lost, the state transition must wait until all
the unRECEIVED data before the FIN is present).  But the TCP connection
does not tell its client that the connection is closed until the
client tries to RECEIVE the FIN.  In practise, this means that you
must maintain the connection state even after it has closed, to allow
the client to receive every last byte of data.

===aside========

While I have your ear, let me sound off about a pet peeve that you
can preemptively fix in your implementation.  The TCP layer should be
willing to remain in zero window state arbitrarily long, as long as
control packets are still crossing the connection.  Don't time out a
connection just because the window is zero for a while.

Last I checked, Apollo (SR 9.2.3), Tops-20, Unix 4.2 all exhibit this bug.

===edisa========

- Geof Cooper
  IMAGEN

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Feb-87 13:29:04 EST
From:      DIXON-R%OSU-20@OHIO-STATE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Proteon vs Arpanet query


We purchased a Proteon P4200 gateway with an Arpanet card to serve as our campus
gateway to Arpanet. We were told that the gateway card supports 1822 DH, so
we specified that to the Arpanet people and have been awaiting arrival of the
Arpanet connection. Now the Arpanet people tell us we must change to 1822 HDH,
and to work that out with our vendor. Proteon says they do not support
1822 HDH.  Now what do we do? Throw out the Proteon box? Forget Arpanet?
Is this a catch-22 situation?

                                      Bob Dixon
                                      Ohio State University

-------
-------

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Feb-87 19:19:06 EST
From:      minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Telnet Option Negotiation to IBMish Hosts

Hi all.  The question of how one gets into "3270 mode" is a one
worth pondering.  A follow up message by Bruce Crabill (which may
not have made it to the tcp-ip list) and the original message by
Mike Hojnowski are fairly worthwhile reading, but I would like
to add my two-cents worth.

First, there is, of course, absolutely NO standard for how "3270 over
telnet" should be done.  The Wisconsin picked something, based possibly
on conversations with the UCLA (MVS) people.  Doing this involved
inventing a new Telnet option (EOR's).  The initial WISCNET just
negtotiated a 3270 terminal type and binary mode, and then assumed
EOR.  After the implementation, the EOR (end of record) RFC came out and
said "thou shalt negotiate EOR prior to using it", so later versions
of WISCNET have negotiated EOR in addition to the terminal type and
binary mode.

Berkeley TN3270 does, in fact, always respond "ibm3278-X" to "send
terminal type".  This is somewhat of a problem, since if we AREN'T
going to get into 3270 mode, we would probably REALLY like to say
"vt100", or whatever the user's terminal REALLY is.  I would LIKE
to see this change, but it's not really too big of a deal.

Berkeley TN3270 does, in fact, check occasionally to see if "binary"
and "terminal type of 3270 sent" are true.  If they are, then Berkeley
TN3270 magically slips into 3270 mode.  If these are NOT true, then
Berkeley TN3270 magically slips out of 3270 mode (which transition
may not work very well - I've never had a host that wanted to leave
3270 mode on me, though I understand that the UCLA code does like
to do this at times).  We DON'T check EOR option being set (though
the current Berkeley TN3270 is willing to have EOR set on either end).

Berkeley TN3270 IS sensitive to the fact that various IBM implementations
are order sensitive when doing the initial negotiations.  The most recently
announced version of Berkeley TN3270 had a "bug" which caused it to
not work when talking with Fibronics/Spartacus/KNET.  The current version
(available on arpa.berkeley.edu, or from me, but never announced)
has a kludge to get around the KNET operating characteristics.

    The problem with order sensitivity is that on start up, a client
    would really like to just send "do sga" and "will terminal type".
    Doing this sort of "parallel" option negotiating can speed up the
    user-perceived connect time a lot.

I would like an agreement on how to do things.  Perhaps an RFC.
I don't think the issues are actually that easy to resolve (though
maybe I'm just slow).

Part of the constraints should be that if 3270 negotiation doesn't work,
we should slip back into "send terminal type" so that (for example)
an Amdahl-compatible machine with an onboard emulator (ala KNET) can
determine the terminal type without having to ask the user.  Also,
the mode should be able to be switch back and forth (for the UCLA people,
if no one else).

The problem with doing an RFC, of course, is "who wants an RFC that only
pertains to one class of terminals" (though the telnet RFC, after all,
spends a lot of time making telnet work for IBM 2741's).

Greg Minshall
CFC 273 Evans Hall
UC Berkeley, Ca.  94720

(ps - this message is partly a sly way of announcing a "fixed" version
of tn3270 available on arpa.berkeley.edu in pub/tn3270tar; the message is
also to announce the availability of tn3270 to the bitnet community)

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Feb-87 20:06:19 EST
From:      THARENOS@IBM.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   FIN-WAIT-2 to TIME-WAIT transition

> The question is, what is a TCP to do if it is in FIN-WAIT-2, it has some
> user data that the user hasn't asked for yet, and a FIN comes in?  If it
> goes immediately to TIME-WAIT (as this TCP does) the user will receive an error
> because RFC 793 says that a RECEIVE call while in TIME-WAIT returns "error:

   Thought I'd take a stab at this one .... The key here is that a FIN implies
a PUSH.   It is the responsibility of your TCP to asyncronously notify the
client that a PUSH has arrived and that a RECEIVE is needed.  If the client is
well behaved, then a RECEIVE should be forthcoming.  However, this is where
your question gets tricky.  Should TCP wait before entering the TIME-WAIT
state for the client to respond with the receive?  This adds a client condition
to the state table of TCP.  If the client was smarter, there would be multiple
RECEIVEs queued and TCP could satisfy the FIN(push) immediately and thus
enter TIME-WAIT without worry.  If, however, your client decides to be a bad
client and wait a few hours before issuing the RECEIVE, then your question
comes to light.  I would venture a guess that TCP should stay in FIN-WAIT-2
until the push signal has been satisfied with a RECEIVE and then enter
TIME-WAIT.

Mike Tharenos <Tharenos@ibm.COM>
Networking Support and Development
IBM, Almaden Research Center
408-927-2727

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Feb-87 23:22:16 EST
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Problem with TCP state transitions in CLOSE

As there was some question as to how 4.2/4.3 handle the receipt of a FIN
with unreceived data, I'll answer that question.  The buffering of received
data and synchronization with the user programs is handled in the (generic)
socket layer in 4BSD.  As data is received and ordered by the TCP,
it is handed to the socket layer to await a receive call.  When a FIN
is received (and all data preceding it), TCP processes the FIN and enters
TIME_WAIT state.  The user process may consume the data at its leisure,
and is notified of the end of data (FIN) after the preceding data is consumed.

		Mike

aside to Geof Cooper re: zero windows:
===aside========

The bug to which you alluded, failure to tolerate persistance of a zero
window, does not occur in 4.2 as you describe it.  4.2 becomes impatient
and closes only if the zero window results from shrinking a window
into which it has already sent data.  It will also reset a connection
when new data is received, but cannot be accepted because the user
process has closed and exited without waiting for the connection to close.

===edisa========

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Feb-87 00:54:14 EST
From:      karn@KA9Q.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP closes

Who says you have to throw away pending data when the TCP connection enters
the CLOSED state? In my implementation I put incoming data on a receive
queue and notify the user with an upcall. The user is entirely within his
rights if he chooses not to read it right away.

When the connection changes state (e.g., from TIME_WAIT to CLOSED) the user
is also notified with an upcall.  However, the control block goes away only
in response to an explicit call from the user.  This gives it a chance to
read any unread data or to throw it away.

Phil

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Feb-87 01:51:59 EST
From:      QUALCOMM@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   nice book on TCP/IP ??

Is there a good book somewhere that describes TCP/IP?
I want something fairly technical (not a Tanenbaum), but not deadly
detailed (ie not the protocol specs).  Something that included some
discussion of many of the related protocols ARP, SMTP, SLIP, TELNET, etc etc
would be especially useful.
-------

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1987 01:51:59 EST
From:      Franklin Antonio <QUALCOMM@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   nice book on TCP/IP ??
Is there a good book somewhere that describes TCP/IP?
I want something fairly technical (not a Tanenbaum), but not deadly
detailed (ie not the protocol specs).  Something that included some
discussion of many of the related protocols ARP, SMTP, SLIP, TELNET, etc etc
would be especially useful.
-------
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1987 at 0827-EST
From:      hsw at TYCHO.ARPA  (Howard Weiss)
To:        DIXON-R%OSU-20 at ohio-state.arpa
Cc:        tcp-ip at sri-nic
Subject:   re: Proteon vs Arpanet query


One pertinent piece of information you left out of your message is where
is the PSN (aka IMP) you are connecting to....  If the PSN is local
to you then DH should be more than adequate.  If you are having
problems getting a DH interface for the PSN then you should go back
to your sponsoring organization and raise your collective organizational
voice.  On the other hand, if the PSN is NOT local and you trying
to connect to one miles away (or more than 2K feet away), then you
really do need HDH.  The only other alternative is to put ECU boxes
on each end of the connection (one at the gateway and one at the
PSN).  This will work just fine (we have lots of ECUs here), but
DDN would rather you didn't throw extra boxes on the line that they
can't remotely diagnose.

Howard Weiss
National Computer Security Center
-------

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Feb-87 09:31:48 EST
From:      hsw@TYCHO.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: Proteon vs Arpanet query



One pertinent piece of information you left out of your message is where
is the PSN (aka IMP) you are connecting to....  If the PSN is local
to you then DH should be more than adequate.  If you are having
problems getting a DH interface for the PSN then you should go back
to your sponsoring organization and raise your collective organizational
voice.  On the other hand, if the PSN is NOT local and you trying
to connect to one miles away (or more than 2K feet away), then you
really do need HDH.  The only other alternative is to put ECU boxes
on each end of the connection (one at the gateway and one at the
PSN).  This will work just fine (we have lots of ECUs here), but
DDN would rather you didn't throw extra boxes on the line that they
can't remotely diagnose.

Howard Weiss
National Computer Security Center
-------

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Feb-87 14:09:00 EST
From:      stanonik@NPRDC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   xerox -> 4.3bsd telnet

Hello,

We recently installed a xerox 1186 (dandytiger?) running koto
release 2.0.  Telneting from the 1186 to our vax 780 running
4.3bsd hangs, apparently because the 1186 doesn't respond to
the vax telnet server's "do terminal-type" negotiation.  The
4.3bsd telnet server waits in a loop for the "will/won't terminal-type"
response, processing options, but not starting a login process.
That seems unforgiving (although seemingly legal) from 4.3bsd.
We've hacked a version of the 4.3bsd telnet server, which omits
the terminal-type negotiation, and put it on another port, but
can't convince the 1186 to try the alternate port.  Anyone else
encountered this (the xerox folks say other sites have 1186s
telneting to 4.3bsd machines)?  Any idea how to convince the
1186 to use an alternate port for telnet?  Or, is 4.3bsd wrong
to "hang" waiting for the "will/won't terminal-type" response?

Thanks,

Ron Stanonik
stanonik@nprdc.arpa

ps.  The 1186 also seems to violate the rfcs by sending the
"terminal-type is" subnegotiation without first receiving
a "terminal send".  Or maybe it thinks that is a suitable
response to "do terminal-type"?

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Feb-87 15:21:00 EST
From:      stanonik@NPRDC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   adding a service to inetd.conf doesn't work

Description:
	Adding a new service to inetd.conf and then HUPing inetd
	doesn't work.  Connections can be made to the port, but
	the connection is closed when anything is sent to the port.
Repeat-By:
	Put a copy of telnet on another port by adding the new
	service, say xtelnet on port 623, to /etc/services, and
	make the appropriate /etc/inetd.conf entry.  HUP inetd.
	Now telnet localhost 623.  The connection is made, but
	hitting any key closes the connection.  The login herald
	is never seen, and what's more, checking the access date
	on the service reveals it wasn't execed.
Fix:
	The problem seems to be that inetd doesn't clear the se_bi
	field when parsing inetd.conf, so se_bi is left flagging
	"internal" after the initial pass through inetd.conf.
	Anything service added afterward is also flagged internal.
	Clear the se_bi field if the service isn't internal.

--- inetd.c	Mon Feb 16 01:08:29 1987
***************
*** 575,581 ****
  		}
  		sep->se_bi = bi;
  		sep->se_wait = bi->bi_wait;
! 	}
  	argc = 0;
  	for (arg = skip(&cp); cp; arg = skip(&cp))
  		if (argc < MAXARGV)
--- 575,582 ----
  		}
  		sep->se_bi = bi;
  		sep->se_wait = bi->bi_wait;
! 	} else
! 		sep->se_bi = 0;
  	argc = 0;
  	for (arg = skip(&cp); cp; arg = skip(&cp))
  		if (argc < MAXARGV)

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Feb-87 18:09:00 EST
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Vertically Moving Congestion  (VMC)


     Hi people.

     From time to time there has been discussion on the list about what 
happens when you try to solve a congestion problem at a particular 
layer.  Vary often you end up solving the problem at the layer you 
wanted only to find that a new layer has become congested.  This can 
be called Vertically Moving Congestion or VMC.

     We've probably all seen VMC happen in many different networks.  I
went to a DECUS not long ago and talked to some DECNET wizards.  They of
course knew of the problem but hadn't addressed it.  I don't think the 
x.25 gang have and I'm not sure about ISO.  I haven't heard a lot about 
this from the TCP/IP bunch either.

     Some time ago I tried to arouse a little interest in VMC on the
list and that's exactly what I got, a little interest. 

     Time has passed and to the best of my knowledge the problem still 
exists (unless somebody snuck the solution by when I was asleep).  I was 
wondering whether or not anyone had given any more thought to the 
following question:  What kind of traffic monitoring/resource use
information needs to be passed vertically to help alleviate the problem?

     Another interesting question:  Is the problem solvable? 

     I've been thinking about this for some years now, ever since I 
first ran into it.  I'm not even sure I've gotten to the rule of thumb 
stage for an answer yet.

     Am I showing my ignorance of the literature here?  Has someone 
solved this behind my back?  Does anybody really care?

     Any takers?  


Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Feb 87 18:09 EST
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Vertically Moving Congestion  (VMC)
     Hi people.

     From time to time there has been discussion on the list about what 
happens when you try to solve a congestion problem at a particular 
layer.  Vary often you end up solving the problem at the layer you 
wanted only to find that a new layer has become congested.  This can 
be called Vertically Moving Congestion or VMC.

     We've probably all seen VMC happen in many different networks.  I
went to a DECUS not long ago and talked to some DECNET wizards.  They of
course knew of the problem but hadn't addressed it.  I don't think the 
x.25 gang have and I'm not sure about ISO.  I haven't heard a lot about 
this from the TCP/IP bunch either.

     Some time ago I tried to arouse a little interest in VMC on the
list and that's exactly what I got, a little interest. 

     Time has passed and to the best of my knowledge the problem still 
exists (unless somebody snuck the solution by when I was asleep).  I was 
wondering whether or not anyone had given any more thought to the 
following question:  What kind of traffic monitoring/resource use
information needs to be passed vertically to help alleviate the problem?

     Another interesting question:  Is the problem solvable? 

     I've been thinking about this for some years now, ever since I 
first ran into it.  I'm not even sure I've gotten to the rule of thumb 
stage for an answer yet.

     Am I showing my ignorance of the literature here?  Has someone 
solved this behind my back?  Does anybody really care?

     Any takers?  


Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Feb-87 23:32:56 EST
From:      rick@suny-sb.CSNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   RDP for Unix


Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or
Sun 3.X Unix?  Any general comments on RDP and its suitability for use
welcomed..

					Rick Spanbauer

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Feb 87 23:32:56 EST
From:      RJ Spanbauer <rick%suny-sb.csnet@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        joes%suny-sb.csnet@RELAY.CS.NET
Subject:   RDP for Unix

Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or
Sun 3.X Unix?  Any general comments on RDP and its suitability for use
welcomed..

					Rick Spanbauer

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 03:19:23 EST
From:      ROODE%BIONET@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Ethernet Security

The Bridges aren't irrelevant in the extent that even as they
may sound elegant in the sense of permitting geographical
growth to occur transparently, they do so at the expense
of the administrative controls normally associable with a physical
ethernet (as few as those may be).

If the gateways were of a less transparent variety, some
additional protection against impersonation would be provided.
If the gateways are sensitive to the identity of the sender
of the packets they are routing, and you trust your gateways,
you have some idea of at least the physical ethernet  on which
packets originate.
-------

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 09:47:27 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Proteon vs Arpanet query


     
     We purchased a Proteon P4200 gateway with an Arpanet card to serve as our campu
     s
     gateway to Arpanet. We were told that the gateway card supports 1822 DH, so
     we specified that to the Arpanet people and have been awaiting arrival of the
     Arpanet connection. Now the Arpanet people tell us we must change to 1822 HDH,
     and to work that out with our vendor. Proteon says they do not support
     1822 HDH.  Now what do we do? Throw out the Proteon box? Forget Arpanet?
     Is this a catch-22 situation?

                                           Bob Dixon
                                           Ohio State University

     -------
     -------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 87 09:47:27 EST (Thu)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Bob Dixon <DIXON-R%OSU-20@ohio-state.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com
Subject:   Re: Proteon vs Arpanet query

     
     We purchased a Proteon P4200 gateway with an Arpanet card to serve as our campu
     s
     gateway to Arpanet. We were told that the gateway card supports 1822 DH, so
     we specified that to the Arpanet people and have been awaiting arrival of the
     Arpanet connection. Now the Arpanet people tell us we must change to 1822 HDH,
     and to work that out with our vendor. Proteon says they do not support
     1822 HDH.  Now what do we do? Throw out the Proteon box? Forget Arpanet?
     Is this a catch-22 situation?

                                           Bob Dixon
                                           Ohio State University

     -------
     -------
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 12:42:53 EST
From:      ron@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   HOST TABLE REDUCTION

I just got some neat automatic mail messages about the internet
host table domain cleanup which points out to me some additional
silliness going on.  Why (this is rhetorical, I know why) are there
hosts listed in the INTERNET HOST TABLE that are not INTERNET HOSTS.
A host on our IMP, PERDIMS-38, is an X.25 PAD, and doesn't know IP
from a hole in the ground.  Yet it is Port 9 on IMP 29 so someone
crafted up a 26.9.0.29 address for it.

-Ron

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 13:26:55 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   nice book on TCP/IP ??


Yes, get Doug Comer's new book Volume II of his "The Design of the
XINU Operating System, an Internetworking Approch" (I think I got that
right, don't have it right here.)

I think a perusal of it will convince you of it's applicability, he
builds an entire implementation module by module, with code and text
explaining it. Includes things like a diskless client/server and other
goodies beyond the standard protocols.

While you're down at the bookstore pick up a copy of Padlipsky's "The
Elements of Networking Style". It's a small tome and explains a lot of
the issues in the design decisions in a, well, let's call it "unique"
style, it's very amusing and worth understanding.

	-Barry Shein, Boston University

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 14:16:01 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Proteon vs Arpanet query


First, let me apologize to the whole list for sending out the previous
message.  It slipped through my fingers while trying to reply.  (An apology is
a bad thing to begin a letter with.)

Bob,
There are two main ways to connect to a PSN at 'level 1', the electrical level.
There is 1822 DH, which is good up to about 1000 feet, and there is 'modem'
which may be RS232, V.35, RS422, and possibly others.

If the arpanet PSN is not in your building, and you cannot get one installed
in your building, you will need some sort of modem connection.  As H.Weiss
pointed out, you could use ECU's to turn the modem line into a DH connection
at your end and at the PSN, but ECU's are impossible for DDN to monitor and
the modem line is also hidden from monitoring also.  

The PSN modem connections are based on HDLC, and can use HDH or X.25 ("DDN
Standard X.25").  You want to see if Proteon will support either of those
protocols.  

Disclaimer:
This is a statement from a PSN user; I run gateways, not PSNs.  I do not
speak for DDN or the PSN support group.

    Mike

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 87 14:16:01 EST (Thu)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Bob Dixon <DIXON-R%OSU-20@ohio-state.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com
Subject:   Re: Proteon vs Arpanet query

First, let me apologize to the whole list for sending out the previous
message.  It slipped through my fingers while trying to reply.  (An apology is
a bad thing to begin a letter with.)

Bob,
There are two main ways to connect to a PSN at 'level 1', the electrical level.
There is 1822 DH, which is good up to about 1000 feet, and there is 'modem'
which may be RS232, V.35, RS422, and possibly others.

If the arpanet PSN is not in your building, and you cannot get one installed
in your building, you will need some sort of modem connection.  As H.Weiss
pointed out, you could use ECU's to turn the modem line into a DH connection
at your end and at the PSN, but ECU's are impossible for DDN to monitor and
the modem line is also hidden from monitoring also.  

The PSN modem connections are based on HDLC, and can use HDH or X.25 ("DDN
Standard X.25").  You want to see if Proteon will support either of those
protocols.  

Disclaimer:
This is a statement from a PSN user; I run gateways, not PSNs.  I do not
speak for DDN or the PSN support group.

    Mike
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 14:56:33 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Proteon vs Arpanet query

Bob,

Faced with a similar problem, we feel the strategy of choice is to use
Standard X.25 and beat up Proteon for its support. Rumor is circulating
that Proteon may have support for that in beta test maybe in a month.
However, you may wish to buck your problem upstairs via your ARPANET
sponsor and squeal like stuck pig.

Dave

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 15:08:52 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  nice book on TCP/IP ??

Frank,

I see you went to work for the good guys. Try the DDN Protocol Handbook
(two volumes plus) available from SRI International for a hundred bucks
and change. The documents include several tutorial papers and overview
articles. I am not aware of a comprehensive book on the subject.

Dave

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 16:54:55 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Telnet Option Negotiation to IBMish Hosts

Mike,

Your recital of the various IBM host implementations of full-screen
3278 operation did not mention the UCLA OS/MVS version, which (almost!)
interoperates with the Wiscvm code.

You incorrectly state that the choice of mode is between ASCII and
EBCDIC encoding.   Suppose there were an EBCDIC option in TELNET... this
would simply be NVT encoded in EBCDIC; the only question would
be whether to use CR LF or NL for end of line. 

Actually, the choice is between NVT and encapsulated IBM 3278 order
streams.  Now, the latter is about as close to binary as anything I
know... it contains command code bytes, cursor positions, repeat counts,
flags, and, encapsulated in all that framing and control, some EBCDIC
text.  It could as well be Display Code or Sanskrit.  The 3278 stream is
BINARY, man!

You state that the Wiscnet implementation requires a fixed order of
negotiation.  That surprises me... in an exchange of mail several years
ago Larry Landweber and I agreed on the following rules:

  The terminal type negotiation and the EOR negotiations may occur
  in any order.  If EOR has been negotiated in both directions and if a 3278
  terminal type has been negotiated, THEN negotiation of BINARY will cause 
  the mode to change from NVT to full-screen-3278.  Note that the BINARY
  is negotiated separately in each direction, which correctly synchronizes
  the mode change (any NVT data in the pipeline in each direction should
  be correctly handled).
  
The UCLA code (v.1.6) does this correctly; I thought that Larry said
the Wiscnet code did also.  

There is a problem with negotiating OUT of full-screen back to NVT.  The
MVS Telnet Server requires this; it negotiates OUT of BINARY, which
returns to NVT. Returning to 3278 mode later in the Telnet connection
requires only negotiating BINARY again; the EOR and Terminal Type
negotiations are assumed to be persistent on the connection.  The Wiscnet
code, because of the hacky way they implemented Telnet using existing VM
features, is unable to change a connection back to NVT mode if it begins
in full-screen mode.

The need for a little RFC on 3278 encapsulation in Telnet has been
repeated pointed out over the past 4 years, but no one has ever felt
they had the time (read $$) to pay for it.  Not Wisconsin, not UCLA,
not IBM FSD, not Berkeley.  If would be wonderful if someone would
write it down... but they had better understand the problem first.
For example, the current spec uses the pre-SNA encoding, which is
probably a mistake.  And it is probably necessary in general to
negotiate not just terminal type but also control unit type, since
different IBM controllers support different wonderful features of
the 3278/etc terminals.

Welcome to the wonderful world of...

   Bob Braden

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Feb-87 19:48:00 EST
From:      mike@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP messages

The idea about having mailers stick around and let TCP go "forever"
to get mail though may be OK if you don't send much mail, but some
of our machines find themselves having to deliver mail to >> 5,000
host/message destinations per day.  It takes us several mailer
daemons running in parallel to punch this much mail through.
Without application level timeouts, talking to dead or overrun hosts
could tie up a significant fraction of our transmission daemon
resources.  Not all mail systems even offer the option of having multiple
transmission daemons, and instead rely on a single daemon for all
mail sending operations.

Clearly, application level timeouts need to be set to reasonable
values.  However, our experience with operating many mail-intensive
machines has been that SMTP servers, even in 1987, have many failure
modes.  SMTP servers can fail to answer after any part of the
transaction, even though their host and TCP connections are still well.
This level of failure can only be dealt with by application level timeouts.

Just as security can only be dealt with across all protocol levels,
the issue of timeouts spans protocol levels as well.
	-Mike

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Feb-87 03:32:17 EST
From:      ins_adsk@JHUNIX.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   remove from list

To whom it may concern:
        Please remove me from  the unix wizards mailing list.  I no longer need
the information from your mailing list sent to my account.  Thank you.
 
                               David S. Kerven (allegra!hopkins!jhunix!ins_adsk)
--------------------------------------------------------------------------------
ARPA:ins_adsk%jhunix.BITNET@wiscvm.ARPA    BITNET:ins_adsk@jhunix
CSNET  :ins_adsk@jhunix.CSNET              USENET:seismo!umcp-cs!jhunix!ins_adsk

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Feb 87 3:32:17 EST
From:      "Erekosse @ Magic-Users' Guild of Gwynedd"  <ins_adsk%JHUNIX.BITNET@wiscvm.wisc.edu>
To:        unix-wizards@brl-sem.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   remove from list
To whom it may concern:
        Please remove me from  the unix wizards mailing list.  I no longer need
the information from your mailing list sent to my account.  Thank you.
 
                               David S. Kerven (allegra!hopkins!jhunix!ins_adsk)
--------------------------------------------------------------------------------
ARPA:ins_adsk%jhunix.BITNET@wiscvm.ARPA    BITNET:ins_adsk@jhunix
CSNET  :ins_adsk@jhunix.CSNET              USENET:seismo!umcp-cs!jhunix!ins_adsk
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Feb 87 10:19:36 -0500
From:      Craig Partridge <craig@loki.bbn.com>
To:        rick%suny-sb.csnet@relay.cs.net
Cc:        tcp-ip@sri-nic.arpa
Subject:   re: RDP for Unix

> Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or
> Sun 3.X Unix?  Any general comments on RDP and its suitability for use
> welcomed..

Rick,

    Yes, there is an implementation of RDP for 4.3.  I wrote it this
fall and have been testing it on weekends since then.  There are 
two other implementations that you might be able to port.  My
implementation also runs on SUNs, although I haven't tested it under 3.X.
(I've never had time nor felt the need to upgrade my SUN-100 from 1.X).
It will just drop into binary UNIX distributions if you can change the
protocol switch table.

    I have not yet worried about distributing the code, since it is
still being revised.  Work is afoot to define RDP version 2, which 
makes some minor revisions in the protocol based on what was learned
from testing this fall, and I'm installing a congestion control mechanism.

    Commenting on suitability for use is a bit difficult.  What do you
want to use it for?  You can use RDP for most of the same applications
you'd use TCP for but you probably don't want to in all cases.  Telnet
with RDP would be a bad idea (lots of 1 character segments).  SMTP and
FTP on the other hand, would probably benefit because RDP appears to
be more robust in the face of loss.  

Craig
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Feb-87 10:43:00 EST
From:      craig@LOKI.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: RDP for Unix


> Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or
> Sun 3.X Unix?  Any general comments on RDP and its suitability for use
> welcomed..

Rick,

    Yes, there is an implementation of RDP for 4.3.  I wrote it this
fall and have been testing it on weekends since then.  There are 
two other implementations that you might be able to port.  My
implementation also runs on SUNs, although I haven't tested it under 3.X.
(I've never had time nor felt the need to upgrade my SUN-100 from 1.X).
It will just drop into binary UNIX distributions if you can change the
protocol switch table.

    I have not yet worried about distributing the code, since it is
still being revised.  Work is afoot to define RDP version 2, which 
makes some minor revisions in the protocol based on what was learned
from testing this fall, and I'm installing a congestion control mechanism.

    Commenting on suitability for use is a bit difficult.  What do you
want to use it for?  You can use RDP for most of the same applications
you'd use TCP for but you probably don't want to in all cases.  Telnet
with RDP would be a bad idea (lots of 1 character segments).  SMTP and
FTP on the other hand, would probably benefit because RDP appears to
be more robust in the face of loss.  

Craig

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Feb-87 14:27:44 EST
From:      ron@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  nice book on TCP/IP ??

Comer's book has nothing to do with TCP.  He devotes a whole
paragraph to it.  Not to say that it isn't a good book, it is.
The book has a goal of building a diskless XINU workstation.
The whole thing is built on a UDP/IP network system.  He goes
into things from the interface on up.  It's good, but don't
expect to learn about TCP from it.

-Ron

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Feb-87 14:37:11 EST
From:      mark@MIMSY.UMD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: mimsy!mark
From: mark@mimsy.UUCP (Mark Weiser)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: nice book on TCP/IP ??
Message-ID: <5532@mimsy.UUCP>
Date: 20 Feb 87 19:37:10 GMT
References: <8702191826.AA14972@bu-cs.bu.edu>
Reply-To: mark@mimsy.UUCP (Mark Weiser)
Organization: PRISM Group, University of Maryland, College Park, MD 20742
Lines: 15

In article <8702191826.AA14972@bu-cs.bu.edu> bzs@BU-CS.BU.EDU (Barry Shein) writes:
>
>Yes, get Doug Comer's new book Volume II of his "The Design of the
>XINU Operating System, an Internetworking Approch" (I think I got that
>right, don't have it right here.)
>
This is a good book, but it has nearly zero about TCP (or SMTP or
other higher protocols) in it.  Lots of IP, and lots of network
applications and low-level network support built from scratch and
justified.  And lots of UDP,  I think.
-mark
-- 
Spoken: Mark Weiser 	ARPA:	mark@mimsy.umd.edu	Phone: +1-301-454-7817
CSNet:	mark@mimsy 	UUCP:	{seismo,allegra}!mimsy!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Feb-87 22:50:14 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  HOST TABLE REDUCTION

Ron,

I'm not worried about that or even those Honeybunch and Sperrysys X.25 gizmos
there, since the table predates IP/TCP anyway. After all, this is an internet
table, not only an Internet table.

Having said that, the challenge for the student is how to fool a triple-X
PAD into connecting to an Internet host on the X.25 side while fronting
for another Internet host on the terminal side, said host speaking serially.
Before you laugh me off the block, consider what has to change in the call-
request packet and how to encode the IPgram on the terminal side. You are
allowed to change the firmware in minor ways. No, it is not a TAC, since
it does not speak TCP. It is a dial-up IP host interface for personal
computers, but where the interface can speak ugly X.28 in dinosaur mode
as well. I might even buy one or two.

Dave

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Feb-87 01:59:53 EST
From:      bruce@THINK.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   HDH timeouts / NSF.ARPA

Starting 2 or 3 days ago, we have been experiencing a very weird
problem.  We (Think.COM, 10.4.0.6) are getting hdh timeouts (resulting
in a hung interface) every time we try to communicate with one
particular host, NSF.ARPA (10.9.0.20).

If we ping (ICMP echo) them with 56 data bytes, everything is OK.  If
we try to ping them with 100 data bytes (or more), we get hdh
timeouts.  Probably has something to do with crossing the 128-byte
frame length.

We are running HDH in packet mode with ACC IF-11/HDH unibus interface.
No problems talking to any other hosts.

Any ideas or similar problems?  This has been reported to NOC as SR#8700483.
Didn't I read here that new HDH code was installed on the PSNs recently?

--bruce

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Feb-87 02:06:52 EST
From:      Lixia@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Vertically Moving Congestion  (VMC)

>     Any takers?

Sure.  I'm working on the problem.  In fact I received your msg just when I
came back from picking up a new print of my draft of a group memo, titled

     "The Interactions of Date Flow Control at Different Protocol Layers"

I can give you a copy when it's done (be a bit patient; I have other things to
do too).

Some brief comments on your message:

- I do not agree with the view of "vertically moving congestion".  Generally
speaking, each data transmission layer (link, network, internet, and transport)
should have a flow control mechanism; each control has its own goals and
responsibilities; none should be missing.

>    Vary often you end up solving the problem at the layer you 
>wanted only to find that a new layer has become congested.  This can 
>be called Vertically Moving Congestion or VMC.

  You got this feeling because in today's networks the control is often missing
at one layer or another (lack of coordiation between layers is also bad).
Missing control at one layer can cause problems showing up at other layers.

- I agree with you that one hardly can find studies that address this problem.

  I wouldn't bother to ask standardization people about it, because they 
don't (SHOULD NOT!) make solutions themselves to unsolved research
problems; they (should) only take over solutions after the research is done
and the running experience with the solutions has been collected.

>  I was 
>wondering whether or not anyone had given any more thought to the 
>following question:  What kind of traffic monitoring/resource use
>information needs to be passed vertically to help alleviate the problem?

  I consider we need two things here: one is a vertical communication channel
that can pass info across protocol layers, another is a good flow control
mechanism that has control parameters that are meaningful to other layers.

  I may not have made the second point clear, let me try an example: with a
file transfer, can you figure out the actual rate at which data are dumped to
the net, by looking at the TCP window size?  You probably can't, because the
throughput depends on the round trip delay too, and because window doesn't tell
you how many retransmissions are made.  But if you can't, the network cannot
either, which means window size is not very meaningful when passed across
layers.

>     Another interesting question:  Is the problem solvable?

I feel the question is a bit too broad or unclear -- what is your definition of
"solvable"?  Anyway, I think the answer is yes by my definition, that is,
congestion can be controlled.

Lixia
-------

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Feb-87 07:16:50 EST
From:      bruce@THINK.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   PSN MTU problem?

Oh, I forgot to mention another problem which I first noticed last weekend.

We are unable to send segments to SRI-NIC.ARPA of size MTU.  This time
NIC is the only host with which I have observed the problem.  If I kludge
our tcp to negotiate a slightly smaller MSS, everything works fine.

On this end, we appear to be getting RFMNs from the long packet, but
NIC evidently isn't seeing it.  The connection stays alive: we
retransmit the long packet, and they retransmit the previous ack.

This is not the standard 4.2/4.3 driver bug of not allocating buffers
at least one greater than MTU.  That was fixed long ago.  But the
symptoms are exactly the same.  This is a NEW problem, and we haven't
changed any tcp/ip code here recently.

Evidently we can RECEIVE mtu-sized packets from the NIC.

--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
  bruce@think.com, seismo!think!bruce, bjn@mitvma.bitnet; +1 617 876 1111

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Feb-87 17:19:24 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Learning TCP


Every so often someone asks for some starting material on Internetworking,
I get asked a lot personally around the University here (esp my students!)

Unfortunately there are several views: How to set up and administer,
how to build one, how to use one, how to get a theoretical and
comparative grasp (eg. a person researching network modeling.)

I don't think there exists any one source for all needs, and not any
real source for some needs. I suggested two just now on this list and
got some flak about one, but none of the flak'ers suggested something
better (does that leave Padlipsky's book as the only source in the
world on understanding TCP? I don't think even he would be comfortable
with that, as much as we both like the book.)

I am not sure why people find the RFCs an uncomfortable place to
start, I assume it is because they (the RFCs) assume you have some
view of the networking milieu (eg. that you intend to build a stream
interface on a packet oriented network, that's not obvious to a
novitiate.) In order to understand a solution a person has to understand
the problem it claims to solve. This can be elusive.

Perhaps, given the relatively recent explosion of TCP/IP (et al) based
networks a new list might be called for aimed at more general
questions, similar to the difference between UNIX-WIZARDS (which is
more like this list) and INFO-UNIX (which might be a new list, INFO-TCP?)

If such a list exists it's interesting that I've never seen it mentioned
here, I'll assume it doesn't exist, I don't see anything in interest-groups.

I don't have the time to organize such a list, nor is it clear I would
be the right person to moderate (if moderation is needed), but perhaps
someone with an interest would step forward.

	-Barry Shein, Boston University

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1987 17:26-EST
From:      CERF@A.ISI.EDU
To:        JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Vertically Moving Congestion  (VMC)
Chris,

Tony Lauck has thought a lot about vertical congestion.  One
interesting idea he had is to mark packets moving towards a
destination with an indication that congestion was encountered.
The receiving site uses this information to help adjust its
window for flow control at the transport level (in addition to
using local information like buffer space).

Oh, Tony is the chief protocol architect for Digital Equip Corp.

The other thing to observe is that congestion can show up in
various ways.  It can result in buffers filling up to limits, it
can result in increased delays, it can show up as reduced
throughput or all of the above.  Also, as lost packets, increased
retransmissions (missing ACKS).  All these need to be thought of
as clues which participants in the comm system can use to attempt
to adapt.  The engineering of an internet is still very much a
matter for R&D, so you should feel encouraged to begin work in
this area.

Vint Cerf
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Feb-87 22:59:00 EST
From:      reilly@wharton-10.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   HDH and X.25


	A while ago, when NSF.ARPA was first being added to the
	Internet, it was noted that there were problems when
	a connection between an node that communicated with the PSN
	using X.25 and one that used an HDH to talk to the PSN.

	It appears this problem has occurred again.  The system
	administrator at UPENN.ARPA (10.4.0.96), which uses an HDH,
	has noticed that his system's connection to the Internet has
	been dropping each time NSF.ARPA connects to send mail to the
	system.

	The people at NSF can't do much about this - let them know
	if you believe that a connection from them is causing your
	HDH problems - send mail to postmaster@note.nsf.gov
	
Starting 2 or 3 days ago, we have been experiencing a very weird
problem.  We (Think.COM, 10.4.0.6) are getting hdh timeouts (resulting
in a hung interface) every time we try to communicate with one
particular host, NSF.ARPA (10.9.0.20).

If we ping (ICMP echo) them with 56 data bytes, everything is OK.  If
we try to ping them with 100 data bytes (or more), we get hdh
timeouts.  Probably has something to do with crossing the 128-byte
frame length.

We are running HDH in packet mode with ACC IF-11/HDH unibus interface.
No problems talking to any other hosts.

Any ideas or similar problems?  This has been reported to NOC as SR#8700483.
Didn't I read here that new HDH code was installed on the PSNs recently?

--bruce

------
------

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 87 22:59:00 EST
From:      "G. B. Reilly" <reilly@wharton-10>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   HDH and X.25
	A while ago, when NSF.ARPA was first being added to the
	Internet, it was noted that there were problems when
	a connection between an node that communicated with the PSN
	using X.25 and one that used an HDH to talk to the PSN.

	It appears this problem has occurred again.  The system
	administrator at UPENN.ARPA (10.4.0.96), which uses an HDH,
	has noticed that his system's connection to the Internet has
	been dropping each time NSF.ARPA connects to send mail to the
	system.

	The people at NSF can't do much about this - let them know
	if you believe that a connection from them is causing your
	HDH problems - send mail to postmaster@note.nsf.gov
	
Starting 2 or 3 days ago, we have been experiencing a very weird
problem.  We (Think.COM, 10.4.0.6) are getting hdh timeouts (resulting
in a hung interface) every time we try to communicate with one
particular host, NSF.ARPA (10.9.0.20).

If we ping (ICMP echo) them with 56 data bytes, everything is OK.  If
we try to ping them with 100 data bytes (or more), we get hdh
timeouts.  Probably has something to do with crossing the 128-byte
frame length.

We are running HDH in packet mode with ACC IF-11/HDH unibus interface.
No problems talking to any other hosts.

Any ideas or similar problems?  This has been reported to NOC as SR#8700483.
Didn't I read here that new HDH code was installed on the PSNs recently?

--bruce

------
------
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Feb-87 00:38:29 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP messages

As I mentioned in my original message, the cost of the extra memory
to keep all those daemons around may be prohibitive. However, I was
suggesting that the *TCP* never give up, not SMTP. Clearly you still need
application-level timers for the reasons you describe (although you can
get into trouble there as well by making them too short). I was saying
that *TCP* perhaps is better off without a give-up timer, especially
if the application has no way to control it.  If the application wants to
give up if TCP can't get the data across, it can set a timer of its  own
before sending its data.  This is more in keeping with the original
philosophy of TCP timers as expressed in the original spec, but nobody
seemed to pay much attention to it.

Phil

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1987 09:25-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        ron@BRL.ARPA
Cc:        hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  HOST TABLE REDUCTION
Ron,  the  reason  your  PAD is in the hosttable is because it is
physically connected to the MILNET and the NIC gets all copies of
connect  orders  for  the MILNET and puts those hosts in the host
table.  This has many benefits (for instance, connect to the  NIC
and   do   a  "WHOIS  IMP  29")  and  isn't  something  we  would
discontinue.  'nuff said?

Mike
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Feb-87 15:42:05 EST
From:      ROODE%BIONET@SUMEX-AIM.Stanford.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   ARPANET Performance problems

Could someone give an update on the latest ARPANET performance
problems?  Has there been a significant recovery?  The last
we have seen on this list was word of the futile attempts
to connect to the former address of a host operating
a root domain server..  Off the list I have heard concerns
about backbone bandwidth insufficiencies and
PSN overloading, exacerbated by gateways in operation off
of the PSN's.  Is more known?   Have others noted intermittent
reduction to a non-operational state, plus an overall
decreased throughput available in reaching other sites?
-------

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 05:44:25 EST
From:      bruce@THINK.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   problems identified

Thanks to Mark Lotter at SRI-NIC, the problem with MTU-sized TCP segments
there is fixed.

Other HDH hosts have had problems with NSF.ARPA.  It appears to be an
X.25-to-HDH problem, which isn't surprising, since the packet frame
lengths are different.  I am avioding talking to them until it is fixed.

--bruce

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 06:59:57 EST
From:      news@decwrl.DEC.COM@dopey.AMD.COM
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: dopey!amdcad!cae780!hplabs!sdcrdcf!trwrb!ucla-an!stan
From: stan@ucla-an.UUCP (Stan Stead M.D.)
Newsgroups: comp.dcom.lans,mod.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc,comp.unix.wizards,comp.unix.xenix
Subject: Wanted: Xenix driver for PC Network/Token Ring
Keywords: network token-ring xenix source driver
Message-ID: <3@ucla-an.UUCP>
Date: 23 Feb 87 05:49:15 GMT
Distribution: usa
Organization: Dept. Anesthesia, Sch. of Med., UCLA, Los Angeles
Lines: 19



We are interested in using the Token Ring or PC Network as a DDN interface
into our local ethernet, to ARPA and beyond.  While it doesn't look that
difficult (it never does) we are reluctant to re-invent the wheel.

What we really need is source code for a PC Network or Token Ring driver. 
Has anyone developed a Xenix driver for either the PC Network boards or
Token Ring?  I have heard that SCO has such a driver, but I do not know
of anyone using it.
	Thanks in advance.

Stanley W. Stead
UCLA School of Medicine / Dept of Anesthesiology
BELL: (213) 206-6238
ARPA: ucla-an!stan@ee.UCLA.EDU
UUCP:  {trwrb|ucla-cs|cepu}\
                            !ucla-an!stan
UUCP: {ihnp4|decvax}!hermix/

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 08:26:00 EST
From:      Kodinsky@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Please Add to List

Please add me to your tcp/ip mailing list.  Thanks

Frank Kastenholz MIT-MULTICS.ARPA

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 12:45:17 EST
From:      kent@DECWRL.DEC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ICMP messages

Gee, this sounds very reminiscent of the (once popular, now extinct?)
Delta-T protocol, a "timer-based connectionless protocol" originally
proposed by Dick Watson at LLNL. It (and the whole class) are wholly
timer based, with a window mechanism for flow control, but no 3-way
handshakes on open/close. The key parameter is the "maximum roundtrip
packet lifetime", or Delta-T. 

By knowing the maximum amount of time any packet will live, you can
start sending data in the first packet because you know all stragglers
will have been discarded. Delta-T essentially assumes everyone is
talking to everyone else all the time, but there are gaps in
conversations. If the gaps are longer than Delta-T, there is no need to
keep state information about. Thus, the protocol state information is
essentially a cache of recent interchanges.

Of course, this all depends on accurate estimates of Delta-T, but then,
so does TCP. Watson proposed a "link timing protocol" which slips in
between an IP-type protocol and a transport-type protocol to provide
the necessary timing information.

I'm not clear on how a Delta-T style protocol fits into a large
internet with many gateways on hops, but it's an interesting class of
protocols to think aboiut, now that it seems that TCP performance and
robustness are turning out to be heavily reliant on accurate timer
estimates.

Cheers,
chris
----------

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 13:30:17 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Learning TCP

The trick to learning the Internet protocols (for me at least) was
knowing where to look for things.  I found these sources to be valuable
for different things.

* RFCs -- for the protocol definition or guidelines to protocol
  implementors
* The networking portions of the operating system documentation -- for
  general overviews of how the protocols fit into the operating system
* Books -- better explanations of the protocols than RFCs, plus examples
  (Tanenbaum comes to mind, but since the book predates the current
  Internet setup a lot of information isn't there, like TCP, EGP, etc.)
* The source code -- when the documentation isn't enough, or something
  is broken
* A guru -- when I can't figure out how to do it myself
* This list -- when I and the guru can't figure out how to do it
  ourselves, or there is no guru
* Conferences -- for sharing information in person, and hearing what the
  gurus have to say

Perhaps some ambitious person with a lot of time on their hands could
write a series of books encompassing all this information.

Fundamental Protocols, anyone? :-)

--gregbo

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 13:58:52 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Ethernet Security

Apologies for the delay; my linkage to the List has been temporarily
broken (for about a month now) and it was only through the good
offices of a colleague that I learned my expertise had been
appealed for/to a week or so ago.

By a happy coincidence, the extra time meant that I was able to
confer with Jon Postel on the subtle technophilosophical
questions posed (during the course of a conversation on a far
less intriguing topic), so my response is actually even more
profound than it might have been had it been more timely.
Of course, on the very first point we couldn't quite agree:
I hold that Ethernet physical addresses must be somewhere
between L 1.9 and L 2.1, whereas Jon says 1.7-2.7 (or was it
.7-2.7?).  We did agree that they can't be at -1 because
that's where X.75 is, and I'm confident they can't be at 0
since whatever "Sevice Access Points" mean they don't seem to
be any better equipped to deal with zero-indexing than any of us.
(Probably a great deal less so, come to think of it.)  I also
believe Jon would agree that if Bob Metcalfe wanted to argue
that in "the real Ethernet/XNS" they could also be viewed as being
at L 3 we'd have to consider such a view favorably, even if
it is rather meta-Physical.  (Didn't mean to be overconstraining:
Dave Boggs could also make the argument--even John Schoch, if I
could remember how to spell his name.)

The even harder problem as to what layer university administrators'
phobias belong in did get a joint resolution, however: 68i.
(The analysis was too involved and esoteric to do justice to in
this medium, unfortunately.)

Thanks for asking; it's always a pleasure to be of service.
(Better CC: me directly for the time being if there's anything
else you want to know: the linkage is still flakey and I won't
even be pretending to glance at all msgs for some time [if ever].)

glossabuccal cheers, map
-------

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1987 13:58:52 EST
From:      PADLIPSKY@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet Security
Apologies for the delay; my linkage to the List has been temporarily
broken (for about a month now) and it was only through the good
offices of a colleague that I learned my expertise had been
appealed for/to a week or so ago.

By a happy coincidence, the extra time meant that I was able to
confer with Jon Postel on the subtle technophilosophical
questions posed (during the course of a conversation on a far
less intriguing topic), so my response is actually even more
profound than it might have been had it been more timely.
Of course, on the very first point we couldn't quite agree:
I hold that Ethernet physical addresses must be somewhere
between L 1.9 and L 2.1, whereas Jon says 1.7-2.7 (or was it
.7-2.7?).  We did agree that they can't be at -1 because
that's where X.75 is, and I'm confident they can't be at 0
since whatever "Sevice Access Points" mean they don't seem to
be any better equipped to deal with zero-indexing than any of us.
(Probably a great deal less so, come to think of it.)  I also
believe Jon would agree that if Bob Metcalfe wanted to argue
that in "the real Ethernet/XNS" they could also be viewed as being
at L 3 we'd have to consider such a view favorably, even if
it is rather meta-Physical.  (Didn't mean to be overconstraining:
Dave Boggs could also make the argument--even John Schoch, if I
could remember how to spell his name.)

The even harder problem as to what layer university administrators'
phobias belong in did get a joint resolution, however: 68i.
(The analysis was too involved and esoteric to do justice to in
this medium, unfortunately.)

Thanks for asking; it's always a pleasure to be of service.
(Better CC: me directly for the time being if there's anything
else you want to know: the linkage is still flakey and I won't
even be pretending to glance at all msgs for some time [if ever].)

glossabuccal cheers, map
-------
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 15:51:57 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP messages

As further argument in favor of my position that TCP should not give up
unless the user process requests it, I have lately been deluged with
complains from users that they and their correspondents are being flooded
with duplicate but incomplete mail messages. It seems that frequently the
net path is just good enough to get a SMTP connection going, but when it
gets to the body of the message, good old Berkeley TCP quickly gives up in
disgust. A half hour later the mailer tries again, ad nauseum. Not only does
this put lots of garbage into people's mailboxes, it wastes net resources
and contributes to congestion collapse.

There is no facility that I know of in our mail system for filtering out
duplicate mail messages, but I don't believe one should really be necessary;
TCP should just be more patient.

I perceive that part of the problem is the fact that many (if not most)
TCP/IP vendors are not the Internet, so they never encounter these problems
on their own.  I would like to make a radical policy suggestion: being a
TCP/IP vendor should be sufficient cause by itself to justify a connection
to the Internet (preferably through a slow and expensive X.25 connection
that THEY have to pay for). The payback in "clean" implementations for the
rest of us will be more than worth it.

Phil

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1987 22:35-EST
From:      CERF@A.ISI.EDU
To:        kent@SONORA.DEC.COM
Cc:        mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: ICMP messages
Delta-T got implemented. Dan Nessett at Livermore had a lot to say
about it out in San Diego at the FCCSET meetng last week. I don't have
Dan's electronic mail address in hand, but you might be able to
find it through the NIC or via Dick Watson if you have that.

The hard problem is insuring that packet lifetimes will stay
constrained to the limit you require - otherwise the protocol
will get confused when old duplicate packets arrive when they
should have been flushed from the system.

Vint
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Feb-87 22:55:23 EST
From:      uucp@seismo.CSS.GOV@dolqci.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)


 
Date: 24 Feb 87 03:49:00 GMT
To: seismo!mod-protocols-tcp-ip@seismo.CSS.GOV
Subject: Submission for mod-protocols-tcp-ip
Responding-System: dolqci.UUCP

Path: dolqci!vrdxhq!seismo!rutgers!sri-unix!hplabs!sdcrdcf!trwrb!ucla-an!stan
From: stan@ucla-an.UUCP (Stan Stead M.D.)
Newsgroups: comp.dcom.lans,mod.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc,comp.unix.wizards,comp.unix.xenix
Subject: Wanted: Xenix driver for PC Network/Token Ring
Keywords: network token-ring xenix source driver
Message-ID: <3@ucla-an.UUCP>
Date: 23 Feb 87 05:49:15 GMT
Distribution: usa
Organization: Dept. Anesthesia, Sch. of Med., UCLA, Los Angeles
Lines: 19



We are interested in using the Token Ring or PC Network as a DDN interface
into our local ethernet, to ARPA and beyond.  While it doesn't look that
difficult (it never does) we are reluctant to re-invent the wheel.

What we really need is source code for a PC Network or Token Ring driver. 
Has anyone developed a Xenix driver for either the PC Network boards or
Token Ring?  I have heard that SCO has such a driver, but I do not know
of anyone using it.
	Thanks in advance.

Stanley W. Stead
UCLA School of Medicine / Dept of Anesthesiology
BELL: (213) 206-6238
ARPA: ucla-an!stan@ee.UCLA.EDU
UUCP:  {trwrb|ucla-cs|cepu}\
                            !ucla-an!stan
UUCP: {ihnp4|decvax}!hermix/

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 01:03:35 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   ICMP messages


I think duplicate and incomplete mail messages as a result of STMP
delivery is a bug in the SMTP implementation, plain and simple. If the
final '.<CR><LF>' is not received the message should have been
discarded. Is it really clear it would be easier to redesign and
re-implement the way TCP handles errors than to simply fix the mailer
agent to wait for a dot?

Really not trying to make a global statement on the issue at hand,
just thought this was not the right example of how to solve a problem.

I had that problem and it turned out that the root cause was a frag bug,
as well as SMTP being too anxious to deliver less than a whole message.

It's all so complicated...

	-Barry Shein, Boston University

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 02:01:31 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP messages


     I am aware of two causes of the multiple-copies-of-the-same-message
bug that are caused by poor design of a version of the Unix SMTP server
that runs in all too many Unix hosts.

     When the end-of-message signal (<CRLF>.<CRLF>) is received, this
server spawns a program that appears to be called "sndmsg" to deliver the
message to all the recipients and it insists upon "sndmsg" running to
completion before it will return a success reply code to the SMTP client.

     The first problem happens when there are lots of recipients of this
message and the server's system is a bit loaded.  Many SMTP clients get
fed up if the server doesn't acknowledge the message within a reasonable
period of time (e.g. 5 minutes).  They decide the server is hung, nuke
the connection and try again later.

     Even if you don't believe in timeouts, you must recognize that not
all systems are pleased to have an SMTP stream waiting forever for a
hung SMTP server.

     The second problem will happen with ANY correctly-coded SMTP client.
Somewhere along the line, "sndmsg" runs into trouble.  The SMTP server
sends a 4xx series message with the extremely informative phrase "sndmsg
balks, try again later".  The message has been delivered to some recipients,
but not to others.  But since this is a "whole message failure", it gets
retried for everybody.

     I hope that we can see the extinction of this version of the Unix SMTP
server soon.  The server should NOT make the client wait while a message is
being delivered.  The "sndmsg balks" bug shows why this behavior is so
wrong-headed.  An acknowledgement should be sent as soon as the end of message
signal is received.
-------

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 04:19:53 EST
From:      DUMAS@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   REPLYS TO SATELLITE GATEWAYS


     Thanks to all  people who took the time to answer to
my request for informations on Satellite gateway.
     We are an educational and research institution in
France, and we intend to develop a satellite gateway  (based on
earth ...) .Our purpose is to interconnect baseband Ethernet
networks using  TCP/IP,  and later ISO Transport Services
on top of the Tcp. The hardware, that we shall use is a French
68000 based machine with a specific bus, running Unix sys 5.

     We shall send later a brief description of our own developments
for peoples interested by the subject.

     I have summarized the answers. They were very useful for us.

==================================================================

Date: 29 Jan 87 10:53:46 EST (Thu)
From: Robert Hinden <hinden@ccv.bbn.com>


Jean-Pierre,

What is a Satellite gateway?  Is that a gateway that is in a
Satellite?

We sell,supply, and operate earth based gateways for several clients,
including DARPA and DDN, which are DOD IP Internet gateway which
connect to a variety of networks, including DDN (1822 and X.25),
Ethernet, Satnet, Wideband, and gateway trunks.  The gateway is based
on the BBN Butterfly Multiprocessor.  Currently we have 19 installed
in locations from Calf. to Europe.  We will be installing an
additonal 25 in the next year or so.


====================================================================
Date: Fri, 30 Jan 87 12:19:32 MST
From: haas%utah-gr@utah-cs.arpa (Walt Haas)

I believe that Vitalink makes some earth stations you could
use with TCP/IP.  They can be reached at

	1350 Charleston Rd.
	Mt. View, CA 94043
	(415) 968-5465
=====================================================================
Date: Tue, 3 Feb 87 09:48:38 pst
From: hplabs!cae780!ubvax!dcrocker@ucbvax.Berkeley.EDU (Dave Crocker)

Ungermann-Bass has a collection of TCP/IP products, including
intelligent PC cards and async terminal concentrators.  IP Routers
(gateways) are in the offing.  The product
line includes the ability to down-load the hardware from a network
management center.  This has been used over a satellite link.

Dave
Software Development
408-562-7678

====================================================================
Date: Tue, 3 Feb 87 12:05:37 pst
From: Robert Michaels <michaels%hplrkm@hplabs.HP.COM>


Hi:

I saw your message on the TCP-IP mailing list asking about experiences
with satellites. We recently made use of a satellite link to connect
IP networks which I think may be of interest.

Our Internet:

HP has built a small internet using cisco AGS gateways equipped with
their 56Kbit serial interface. The network connects divisions in the
bay area via HP's Bay Area Microwave network. It also ties in divisons
in Oregon and Colorado via a 56kbit channels on our leased T1 lines.
In Palo Alto the various buildings are interconnected via a broadband
system.

The Satellite Link:
It was the above network we wanted to connect to the show network at the
UniForum trade show in Washington DC two weeks ago. We contracted VitaLink
to provide the dish and technician at the convention and used HPs own
equipment here in Palo Alto. The link was 56Kbit, running on  KU band.
In Palo Alto we have a 3.7m dish and at the convention they used a 1.8m
dish. All hardware including modems and RF amp are built by Vitalink.
The modems have a simple V.35 connection - which meant all we had to do
was convert the V.35 to RS232 so it could connect to the cisco AGS.
The link worked very well - delay was not objectionable. The only problem
we had was snow, however, VitaLink has a dial in system via land lines
to their modems and was able to detect the attenuation of the signal and
alert the technician to sweep out the dish. (permanent installations have
shields to protect against snow and ice).

About the cisco boxes:

The access control features of the gateway were very useful in controlling
who had access to our internet. The lack of a V.35 interface is annoying
but Black Box makes a good little hack. I see this TransLAN (DEC Bridge100)
thing as a major loose. At the convention we also used a 9600 baud dial
up modem as a back-up if the satellite link failed. We ran both links
simultaneously - something we could never do with TransLAN. Well, that's
not true, we could connect both links but TransLAN would detect the a
"loop" and promptly shut down one of the links.

Hope this is of interest to you.

Regards,
Robert Michaels
================================================================
        +--------------------------------------------------+
        | Gerard H. Gaye                                   |
        |  CEN Saclay                                      |
        |                                                  |
        |    gaye@frsac11 (bitnet)                         |
        |    gaye%frsac11.bitnet@wiscvm.wisc.edu (arpanet) |
        |                                                  |
        |    also: dumas@sumex.stanford.edu                |
        +--------------------------------------------------+
-------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Feb 87 08:48:10 -0500
From:      Craig Partridge <craig@LOKI.BBN.COM>
To:        karn%flash.bellcore.com@sh.cs.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   TCP vs SMTP (was ICMP and TCP)

Phil,

    Any sense of which kinds of mailers (i.e. Sendmail, MMDF, something else?)
are generating the duplicate messages?

    There are timers at the SMTP level in many implementations (limiting how
long one is willing to wait before receiving a reply to a command) and
since the congestion problems started I've felt that we needed to look
more carefully at SMTP timer policies.  I actually started on this
task, and rapidly concluded I didn't have the time to do the necessary
research to devise a better algorithm than those already in use.

Craig

"Timers, always the timers...."
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 09:10:42 EST
From:      craig@LOKI.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP vs SMTP (was ICMP and TCP)


Phil,

    Any sense of which kinds of mailers (i.e. Sendmail, MMDF, something else?)
are generating the duplicate messages?

    There are timers at the SMTP level in many implementations (limiting how
long one is willing to wait before receiving a reply to a command) and
since the congestion problems started I've felt that we needed to look
more carefully at SMTP timer policies.  I actually started on this
task, and rapidly concluded I didn't have the time to do the necessary
research to devise a better algorithm than those already in use.

Craig

"Timers, always the timers...."

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 10:43:27 EST
From:      matt@ODDJOB.UCHICAGO.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   SUPDUP

Are there any available SUPDUP implementations for 4.X BSD?

	Matt Crawford

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 11:36:12 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ICMP messages

Chris,

All the present and proposed "transaction" protocols (Birrell&Nelson,
VMTP, SEP, TTP, etc.) being discussed in the End2end Taskforce do in
fact depend upon the Delta-T concept (which you have so cogently
summarized) to avoid an initial handshake. Delta-T was never "popular",
since it was implemented only at LBL; it is much less well known in our
field than it deserves.  Dick Watson thought through the consequences
of his assumptions more thoroughly than we often do, and his papers are
recommended reading for anyone new to the protocol design field.

Bob Braden
 

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 12:42:10 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP messages

Granted, sendmail is royally screwed up and it shouldn't deliver a partial
message.  But I still think that TCP shouldn't give up so easily.  Most of
our network outages are caused by one of several things: our Telenet X.25
interface wedges, csnet-relay's IMP interface wedges (speculation), and/or
our route drops out of the EGP tables.  If TCP just kept trying but backing
off on each retransmission, it wouldn't have to start over when service
resumes, our load on the network would decrease, and sendmail wouldn't have
to contend with message fragments in the first place.  Needless to say, this
also implies disabling the TCP keepalive feature that was hacked into BSD.

Phil

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 14:36:30 EST
From:      jordan@UCBARPA.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  duplicate message in SMTP ("sndmsg balks, try again later")

mark crispin,

i have seen this behaviour as well, but found it not on the UNIX side
(alas, sendmail has no routine sndmsg() ...), but on the side of a VMS
machine running some sort of SMTP (software tools?) that manages to
exceed sendmail's fondness for mangling headers ... and i agree that
once the message has been received, a 2xx acknowledgement is in order;
not quite sure why sendall() in sendmail comes before the 2xx ack.

/jordan

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 15:33:12 EST
From:      jordan@UCBARPA.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   a clarification

(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from
Wollongong's VMS mailer ...

egged-face,

/jordan

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 16:17:14 EST
From:      streeter@1141g.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

Date: 24 Feb 87 21:11:54 GMT
To: ingr!uahcs1!scbhq!sb6!akgua!gatech!mod-protocols-tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Responding-System: 1141g.UUCP

Path: 1141g!streeter
From: streeter@1141g.UUCP (Guy Streeter)
Newsgroups: mod.protocols.tcp-ip
Subject: socket to TLI translation?
Keywords: sockets, tli
Message-ID: <168@1141g.UUCP>
Date: 24 Feb 87 21:11:54 GMT
Distribution: usa
Organization: Society for the Happily Mediocre
Lines: 9

We have some applications based on sockets, and we have a TLI interface.
What we need is to translate between the two.  Has this been done? 
Could someone point out literature or source code that would aid us in
implementing an interface between Sockets and the Transport Layer
Interface?

thanks,
Guy Streeter
akgua!ingr!guy!streeter

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 17:33:00 EST
From:      SRA@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   SUPDUP


    Date: Tuesday, 24 February 1987  10:43-EST
    From: "Yow!  I've been EXIT POLLED" <matt@oddjob.uchicago.edu>

    Are there any available SUPDUP implementations for 4.X BSD?

Yes.  Send mail to bug-supdup@borax.lcs.mit.edu to get in touch with
whoever hacks it these days.  It was written by Dave Bridgham, then of
MIT, now with FTP Software.  It works very well, allowing for the lack
of operating system support for things like %PIATY signals.

--Rob

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Feb-87 21:47:03 EST
From:      ron@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  duplicate message in SMTP ("sndmsg balks, try again later")

I that sndmsg (451 sndmsg balks!) was the BBN C70 UNIX mail system.

Jordan is right, neither sendmail or MMDF does this.  MMDF closes
the file it was writing the message into, queues the message, and
sends the return code.  It does not verify the message at that the
final dot point.  It just makes sure it has stored the message so that
subsequent failures can make use of the return path to send the
failed mail messages.

-Ron

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Feb-87 08:15:00 EST
From:      larry@pdn.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: pdn!larry
From: larry@pdn.UUCP (Larry Swift)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Vertically Moving Congestion  (VMC)
Message-ID: <651@pdn.UUCP>
Date: 25 Feb 87 13:14:59 GMT
References: <8702200048.AA02250@ucbvax.Berkeley.EDU>
Reply-To: larry@pdn.UUCP (0000-Larry Swift)
Organization: Paradyne Corporation, Largo, Florida
Lines: 17

In article <8702200048.AA02250@ucbvax.Berkeley.EDU> JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes:
>Vary often you end up solving the problem at the layer you 
>wanted only to find that a new layer has become congested.  
>
That's why the OSI Reference Model has some form of flow control in *all*
layers one thru five.  The Session Layer (layer 5) is where the data path is
finally narrowed to a single user, and therefore s/his ability to consume
network resources can be limited there.

There are many good reference works on the OSI Model.
--------------------------------
Larry Swift
UUCP: {ihnp4,gatech,cbosgd}!akgua!usfvax2!pdn!larry
Snail mail: LF-207, Paradyne Corp., 8550 Ulmerton Road, Largo, FL, 33541
Phone: (813) 530-8605

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Feb-87 11:24:22 EST
From:      cetron@UTAH-CS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: a clarification

In article <8702242033.AA21637@ucbarpa.Berkeley.EDU> jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) writes:
>(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from
>Wollongong's VMS mailer ...
>
>egged-face,
>
>/jordan

	Don't feel quite so bad, the software tools mailer is somewhat similar:

After it receives the 'terminating' <cr><lf>.<cr><lf> it spawns off a subshell
which attempts to send the receive message header information to a mailer
daemon....if the send works (address is valid, header info complete, etc) then
it returns and the SMTP server responds with the OK message.  If not, it sends
the appropriate error code (syntax error in address - see RFC 822, date missing
etc...).  There IS a window where the remote mailer could time out, but to date
I have never seen this actually happen - remember, it is NOT  trying to deliver
the message, just verify the headers and queue it for delivery.....

-ed cetron
cetron@utah-cs.arpa

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Feb-87 12:21:39 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP messages

Phil,

While not planting feet securely in either camp (you both have valid
points), it's amazing how your perspective changes when operating a
dinky Ethernet between an ARPANET gateway and another gateway to a vast
swamp and when all paths to that swamp have died for a week. You start
searching for words like "M16 effect" to describe the carnage
as the pileup of multiple j-random hosts try to slosh mail across the
dink. Howcum that mail got as far as the dink? Well, turns out the
swamp in question had no way to declare itself down. Jack Haverty, where
are you when we need you? Grumble-mumble and back to work.

Dave

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Feb-87 14:45:57 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Delta-T Paper

We Computer Technologists are noted for standing on each other's toes rather
than each other's shoulders [I first heard that metaphor from Alan Newell
in 1966, but it has also be attributed to Herb Simon], when we make what
we like to think of as progress.  If this sounds like a collective rebuke,
it is.

Since the recent exchange about Delta-T, I have received three different
requests for a reference to Dick Watson's work.  The requestors were all
well-known members of this community; that is both the good and the bad
news.

So that I will not have to send it out yet again...

IEN193, which is a reprint of "Timer-Based Mechanisms in Reliable Transport
   Protocol Connection Management" (Computer Networks, 5 (1981) 47-56). 
 
An important and interesting paper.  Dick, I think you are on this mailing
list, can you suggest any other paper on your Delta-T work?

Bob Braden

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Feb-87 14:50:19 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   tcp counters


For each type of host implementation of IP/TCP/TELNET, where may the tcp error
counters be found?  I realize that some UNIX(tm) systems and derivatives
provide a netstat command with a '-s' option that gives the following counters
for the tcp level.

tcp:
	0 bad header checksums
	0 bad header offset fields
	0 incomplete headers

The information I am looking for is a measure (either per-connection or over
the whole operation of the tcp protocol layer)

 retransmissions - count of segments resent because ack was not returned in time
 redundant receives - count of segments received more than once
 estimated round trip time (per connection) - delay to destination
 retransmission time (or algorithm from est. RT time)
 route (on UNIX() can get this from netstat -r) - gateway or interface used
 when a connection is closed, the reason for closing


For your implementation, are these sort of numbers available to me, a lowly
user, and if not, can a wizard get them using some debugging magic?

Implementations ::= { tops20, 4.*bsd, bbnos, ultrix 1.*, 2.*, vms(wolongong),
		      many others? }

I have taken a call from a user who is unable to reliably get from host A to
host B, in that the connections hang for long periods of time, and frequently
break (connection closed).  While there are 3 different kinds of gateway in
this particular path, I think the routing and traffic load are stable enough
to support useful ftp and telnet service.  I want to be able to have her call
her host wizard to find out what is failing at the end points.

	mike

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 87 14:50:19 EST (Wed)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        tcp-ip@sri-nic.ARPA
Cc:        brescia@ccv.bbn.com
Subject:   tcp counters

For each type of host implementation of IP/TCP/TELNET, where may the tcp error
counters be found?  I realize that some UNIX(tm) systems and derivatives
provide a netstat command with a '-s' option that gives the following counters
for the tcp level.

tcp:
	0 bad header checksums
	0 bad header offset fields
	0 incomplete headers

The information I am looking for is a measure (either per-connection or over
the whole operation of the tcp protocol layer)

 retransmissions - count of segments resent because ack was not returned in time
 redundant receives - count of segments received more than once
 estimated round trip time (per connection) - delay to destination
 retransmission time (or algorithm from est. RT time)
 route (on UNIX() can get this from netstat -r) - gateway or interface used
 when a connection is closed, the reason for closing


For your implementation, are these sort of numbers available to me, a lowly
user, and if not, can a wizard get them using some debugging magic?

Implementations ::= { tops20, 4.*bsd, bbnos, ultrix 1.*, 2.*, vms(wolongong),
		      many others? }

I have taken a call from a user who is unable to reliably get from host A to
host B, in that the connections hang for long periods of time, and frequently
break (connection closed).  While there are 3 different kinds of gateway in
this particular path, I think the routing and traffic load are stable enough
to support useful ftp and telnet service.  I want to be able to have her call
her host wizard to find out what is failing at the end points.

	mike
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1987 21:16-EST
From:      CLYNN@G.BBN.COM
To:        brescia@CCV.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: tcp counters
Mike,

For TOPS-20 systems running the BBN network software, a "lowly user"
should first try TSTAT;  it doesn't give error counters, but may give
insight about hung connections.  If run a user runs it under the same
job as the one owning the problem connection, give it JOB; otherwise
just a <return> to see all connection & find the one(s) of interest.
By looking twice, one can see changes in sequence numbers, windows,
and round trip time.

@tstats
TCB ID: >
J/L JCN/Id Flg State Sequence   Una Wndow RTT/MxS Un/Baud Net+Host   Port
 14.   4. R:O   EST   21132187.       2465.   107.    0. F:128.89.0.87 0.23 
      78. S:OV  EST  933691537.    0. 1932.   964.   34C L:192.1.2.67 131.135 
 5607674
  0.   6. R:O   EST   11965583.       2630.   404.  176. F:192.1.2.12 0.9 
 66 3236. S:OV  EST   87128682.    0.  363.   536.   12C L:192.1.2.67 0.23 
 5624271
@

If that doesn't show what is happening, other per-connection information
can be examined, by name, using either the .IPRIP function of the IPOPR%
jsys, the .TCRTC function of the TCOPR% jsys, or the STAT% jsys (TSTATS
uses the IPOPR% jsys).

TCRPC	# pkt received			TCSPC	# Pkt sent
TCIGN	# pkts ignored			TCRXP	# Pkt retransmitted
TCDUP	# duplicates recvd		TCRZW	# retransmitted into 0 window
TCROS	# out of sequence
TCRST	# RST received			TSTO	Send time out(ms)

TCICM	# ICMP msgs recvd		TCABI	aborted due to inactivity
TCIDU	#  Dest unreachable		TCABR	aborted due to RX timeout
TCIPB	#  Parameter problem		TCERR	TOPS20 error code
TCIRD	#  Redirect msgs recvd		TERR	BBN error code
TCISQ	#  Source Quench msgs recvd
TCITE	#  Time exceeded

A program which shows many of these (but which requires wheel capabilities
for other reasons) is TCPEEK;  it wants the ID and TCP connection block
address (as listed by TSTATS):

@tcpeek
~ TCB ID(10): 3236  MONITOR ADDR(8): 5624271
TCBID TJCN TOWNR TOFRK TFH          TFP TLH          TLP TSMRT TRXP TSTO  
3236  6    0     6     #30000201014 #11 #30000201103 #27 404   #0   900000
TERR TSTAT    TVTL
#0   #2077164 #66 
TRIS     TRLFT    TRLAK    TRWND TRLWN    TRURP    TRBS
11965292 11965583 11965583 2630  11968213 11965292 0   
TCRCV TCRPC TCDUP TCIGN TCROS TCRZW TCEWN TCPCC TCRST TCRPU TCRUR
0     526   0     0     0     0     0     0     0     0     0    
TSIS     TSLFT    TSSEQ    TSWND TSURP    TSBYT TSCB TSCPK
87097344 87128682 87128682 363   87128377 0     #0   #0   
TCSND TCSPC TCRXP TCRXF TCPZA TCFWN TCFWT TCSPU TCSUR
0     633   76    13    167   30    7314  625   3    
TCICM TCISQ TCIRD TCFWP
0     0     0     0    
TSMXS TCRTM    TCATM    TCLTM    TCBTP    TSPRB   
536   43589016 44220791 47535287 47535287 44220791
TCSAG TCFAK TIFDF TTTL TTOS TABTF TCABI
0     0     0     60   #0   #0    0    

~ TCB ID(10): 78  MONITOR ADDR(8): 5607674
TCBID TJCN TOWNR TOFRK TFH          TFP TLH          TLP     TSMRT TRXP TSTO   
78    4    14    8     #20026200127 #27 #30000201103 #101607 107   #0   3600000
TERR TSTAT   TVTL
#0   #277164 #0  
TRIS     TRLFT    TRLAK    TRWND TRLWN    TRURP    TRBS
21128641 21132187 21132187 2465  21134652 21128641 472 
TCRCV TCRPC TCDUP TCIGN TCROS TCRZW TCEWN TCPCC TCRST TCRPU TCRUR
158   709   495   0     0     0     0     0     0     156   0    
TSIS      TSLFT     TSSEQ     TSWND TSURP TSBYT TSCB TSCPK
933691392 933691537 933691537 1932  0     0     #0   #0   
TCSND TCSPC TCRXP TCRXF TCPZA TCFWN TCFWT TCSPU TCSUR
113   697   1     0     101   1     187   113   0    
TCICM TCISQ TCIRD TCFWP
0     0     0     3    
TSMXS TCRTM   TCATM   TCLTM    TCBTP    TSPRB  
964   2440011 2440011 47633921 47633921 2440011
TCSAG TCFAK TIFDF TTTL TTOS TABTF TCABI
0     0     0     60   #0   #0    0    
e  quitting...
@

If that isn't enough, a packet trace might show what is happening.
The easiest way for a "lowly user" to get one, if the TOPS20 is
connected to an 1822 net, is to use the TCPU program.  It creates a
logical host and will pass (tcp) packets between two other hosts,
recording them in the process.  Instead of A telneting to B, tell TCPU
to pass packets between A and B, then telnet from A to the logical
host.  Note that in this case, netiher A or B need be a TOPS20, but
the route that the packets takes will be longer (through the 20 such
as those at BBN), and there will be a little added delay (TCPU is a
user-level program).  [A wheel can get a packet trace of any/all
pcakets through a 20 without a user's cooperation.]

Charlie
PS: See BBN Report 5925 for details and examples of the above.
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Feb-87 22:31:41 EST
From:      streeter@1141g.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

Date: 25 Feb 87 23:00:15 GMT
To: ingr!uahcs1!scbhq!sb6!akgua!gatech!mod-protocols-tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Responding-System: 1141g.UUCP

Path: 1141g!streeter
From: streeter@1141g.UUCP (Guy Streeter)
Newsgroups: mod.protocols.tcp-ip
Subject: internetwork routing
Keywords: routing
Message-ID: <170@1141g.UUCP>
Date: 25 Feb 87 23:00:14 GMT
Distribution: usa
Organization: Society for the Happily Mediocre
Lines: 8

Could someone point me to literature, specs, or source that would help
me implement internetwork routers for TCP-IP?  Is there a MIL-STD for
this?

thanks
Guy Streeter
akgua!ingr!1141g!streeter
 

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Feb-87 23:52:15 EST
From:      ken@HAMLET.CALTECH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: a clarification

>In article <8702242033.AA21637@ucbarpa.Berkeley.EDU> jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) writes:
>>(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from
>>Wollongong's VMS mailer ...

    Wollongong's SMTP server spawns a subprocess (called SNDMSG) to
pass the message off to VMSmail. If the subprocess exits fatally, you
get the `sndmsg balks' error.

>	Don't feel quite so bad, the software tools mailer is somewhat similar:
>
>After it receives the 'terminating' <cr><lf>.<cr><lf> it spawns off a subshell
>which attempts to send the receive message header information to a mailer
>daemon....if the send works (address is valid, header info complete, etc) then
>it returns and the SMTP server responds with the OK message.  If not, it sends
>the appropriate error code (syntax error in address - see RFC 822, date missing
>etc...).  There IS a window where the remote mailer could time out, but to date
>I have never seen this actually happen - remember, it is NOT  trying to deliver
>the message, just verify the headers and queue it for delivery.....

    Correction. The Software Tools SMTP receiver does not spawn a
subshell and does all of the verification as the headers come in. It
then queues the message to the mailer daemon which does little more
than expand aliases and copy the file into the delivery queue
directory before returning a success status to the SMTP receiver,
which is then free to return a response to the SMTP partner.

    Any delay seen between <CR><LF>.<CR><LF> and the response code is
due to the time it takes the mailer daemon to copy the file into the
queue. If this is not done syncronously then a machine failure might
cause lost mail. I'd rather get two than none.

					      Kenneth Adelman
					      Caltech

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 00:00:54 EST
From:      tcs@USNA.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Domain host TTL fields

Something that I've not seen discussed on this list is the optimum TTL
values for host entries, etc in the domain database.  Anyone have any
numbers on the amount of traffic this stuff generates and the affect this
number has on network traffic?

For most large hosts, a minimum of 24 hours seems reasonable and 7
days would not be out of line.  Small workstations that move around a
lot could have smaller values.  Some hosts have a TTL value of 4 hours.
Is this really necessary?  Administrators of zones should be able to
identify major hosts which don't change very often and increase the TTL
accordingly.  The value could be reduced to a few hours prior to a change.

Also, what should be a good value for the nameserver timeout in waiting
for a reply.  I've found that we typically time out two or three times
before receiving a reply.  This means that several extraneous packets
are injected into the network each time we attempt to resolve an
address.

Am I'm missing some issues regarding these values?

	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 05:30:40 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Excelan VMS and microMVS

Can anyone comment on the Excelan VMS and MicroVMS implementations?  Good?
Bad?  Plz reply directly to me so as not to flood the list with too much
unnecessary comments.
 
Thanks,
Hank

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 09:00:28 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   MICOM-Interlan

For that matter can anyone comment on the MICOM-Interlan Tcp/Ip implementation
for VMS and microVMS?  Good Bad?  Once again, reply directly to me.
 
Thanks,
Hank

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 10:58:35 EST
From:      dougm%ico.ISC.COM%ncar.CSNET@RELAY.CS.NET.UUCP
To:        mod.protocols.tcp-ip
Subject:   AT&T RFS over TCP

We're in the process of bringing RFS up over TCP and were
wondering if there was a specific TCP port being used by
other people working on the same thing.

		Thanks,
		Doug McCallum
		dougm@ico.ISC.COM

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 13:39:55 EST
From:      kent@DECWRL.DEC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Delta-T Paper

Here are the references in my bibliography:

@Article(Fletcher:Delta-t,
	Author="John G. Fletcher and
		Richard W. Watson",
	Title="Mechanisms for a Reliable Timer-Based Protocol",
	Journal="Computer Networks",
	Volume="2",
	Year=1978,
	Pages="271-290",
	Note="Introduces the Delta-T concept"
	)

@TechReport(Watson:Delta-tProt,
	Author="Richard W. Watson",
	Title="Delta-t Protocol Specification",
	Type="UCID",
	Number="19293",
	Institution="Lawrence Livermore National Laboratory",
	Month="April 15",
	Year=1983
	)

@TechReport(Watson:deltaGram,
	Author="Richard W. Watson",
	Title="DeltaGram Protocol Specification",
	Type="UCID",
	Number="19295",
	Institution="Lawrence Livermore National Laboratory",
	Month="August 3",
	Year=1982
	)

These are all part of the LINCS (Livermore Interactive Network
Communication System) document series, most of which are LLL tech
reports. I last investigated Delta-T in 1983, so my copy of the
bibliography may be out of date.

chris
----------

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 14:04:02 EST
From:      jb@cs.brown.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Domain host TTL fields

Over time, my idea of what the optimum time should be has been increasing.
In general, I feel that 24 hours is about the correct value.  One major
issue is how long various other software will wait for a change.  Sendmail
will attempt to deliver a message for 3 days (as distributed).  One would
like to have any changes seen in less than 3 days.

There are a couple reasons for data to change.  First, a planned change to
the network configuration.  This can be planned for in advance by reducing
the TTL.  Don't forget that the reduction must be made at a time longer
than the TTL in advance.  Consider how long in advance you would be planning
a move.  Another reason for a change is due to an unanticipated failure.
If one of your primary machines (such as a mail forwarder) goes down
for a few days, attempts to bypass the failure require the length of the
TTL to be fully realized.

Coming from Berkeley and being involved with some of the early distributions
of BIND, I'll admit we made a mistake in what we had in the sample files.
Many people just copied our samples and did not analyze the situation.  Our
samples should have had TTL's that were longer than 1 hour.  We did not
realize this originally ourselves and were guilty of using too short
of a TTL for a long time.  These problems take time to work out.

As far as the question of what should be used as the timeout waiting for
a reply, I'm not sure of what is the correct answer.  There are 3 timeouts
to consider in this case.  First, total time to wait for any response before
indicating a failure.  Second, the time between trying different servers
for the domain.  And third, the time between tries to the same server.

The first of these is a user interface question on one hand, and a performance
issue on the other.  How long should a user who tries to telnet to some host
have to wait before being told that the host is unknown (possibly only
temporarily)?  I don't like to wait a long time, but on the other hand,
the longer the wait the more likely to succeed.  BIND is currently using
about one minute for this.

The other two are intertwined and also are a part of the first one.  UDP
which is used primarily for queries is not reliable.  If one knows that
the original packet was lost, then a retry to one of the servers is in
order.  If the delay is in network round trip time (RTT), then the time
between the retries should be lengthened.  

To decide what these times should be, several questions to be answered.
How long should the user wait for a response?  How many queries total
should be sent out in trying to resolve the name?  How many queries should
be made to each server for the domain?  What should the retry algorithm
be (linear, exponential, something else)?  If recursion is being done
by another process, how does that affect these values?

I'm not sure what is being used in BIND at the moment.  It actually uses
two different algorithms.  One for talking to the local server, and another
for dealing with recursion.  Some work on the algorithms has been done for
the most recent release and I haven't had a chance to look at the code.

					Jim Bloom

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Feb 87 14:04:02 EST
From:      Jim Bloom <jb%cs.brown.edu@RELAY.CS.NET>
To:        tcs@USNA.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Domain host TTL fields
Over time, my idea of what the optimum time should be has been increasing.
In general, I feel that 24 hours is about the correct value.  One major
issue is how long various other software will wait for a change.  Sendmail
will attempt to deliver a message for 3 days (as distributed).  One would
like to have any changes seen in less than 3 days.

There are a couple reasons for data to change.  First, a planned change to
the network configuration.  This can be planned for in advance by reducing
the TTL.  Don't forget that the reduction must be made at a time longer
than the TTL in advance.  Consider how long in advance you would be planning
a move.  Another reason for a change is due to an unanticipated failure.
If one of your primary machines (such as a mail forwarder) goes down
for a few days, attempts to bypass the failure require the length of the
TTL to be fully realized.

Coming from Berkeley and being involved with some of the early distributions
of BIND, I'll admit we made a mistake in what we had in the sample files.
Many people just copied our samples and did not analyze the situation.  Our
samples should have had TTL's that were longer than 1 hour.  We did not
realize this originally ourselves and were guilty of using too short
of a TTL for a long time.  These problems take time to work out.

As far as the question of what should be used as the timeout waiting for
a reply, I'm not sure of what is the correct answer.  There are 3 timeouts
to consider in this case.  First, total time to wait for any response before
indicating a failure.  Second, the time between trying different servers
for the domain.  And third, the time between tries to the same server.

The first of these is a user interface question on one hand, and a performance
issue on the other.  How long should a user who tries to telnet to some host
have to wait before being told that the host is unknown (possibly only
temporarily)?  I don't like to wait a long time, but on the other hand,
the longer the wait the more likely to succeed.  BIND is currently using
about one minute for this.

The other two are intertwined and also are a part of the first one.  UDP
which is used primarily for queries is not reliable.  If one knows that
the original packet was lost, then a retry to one of the servers is in
order.  If the delay is in network round trip time (RTT), then the time
between the retries should be lengthened.  

To decide what these times should be, several questions to be answered.
How long should the user wait for a response?  How many queries total
should be sent out in trying to resolve the name?  How many queries should
be made to each server for the domain?  What should the retry algorithm
be (linear, exponential, something else)?  If recursion is being done
by another process, how does that affect these values?

I'm not sure what is being used in BIND at the moment.  It actually uses
two different algorithms.  One for talking to the local server, and another
for dealing with recursion.  Some work on the algorithms has been done for
the most recent release and I haven't had a chance to look at the code.

					Jim Bloom

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 16:03:37 EST
From:      cam@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

Folks,

Does anyone know if someone has ported tn3270 to run on VMS with
Wollongong's TCP/IP? Or if someone is working on it?

Chris Markle (cam@acc-sb-unix or 301-290-8100)

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 18:20:10 EST
From:      brian@sdcsvax.ucsd.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: sdcsvax!brian
From: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  duplicate message in SMTP ("sndmsg balks, try again later")
Message-ID: <2766@sdcsvax.UCSD.EDU>
Date: 26 Feb 87 23:20:09 GMT
References: <8702241936.AA19824@ucbarpa.Berkeley.EDU>
Reply-To: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Distribution: world
Organization: UCSD wombat breeding society
Lines: 71

This is a message I sent a few weeks ago to someone locally who was
seeing this problem.  Some of the information in here is therefore
UCSD-specific, but you'll get the idea....
-----
More than you ever wanted to know about VMS SMTP mail:

Brief description of problem: mail addressed to many recipients on a
VMS machine has been received as multiple duplicates by some of the
recipients.

What's going on: When mail is sent over an SMTP connection such as is
used on the ethernet, a RCPT TO:<address> line is sent for each
individual recipient to be delivered to on that connection (i.e., on
that host).  The receiving mailer (in this case, the Wollongong VMS
mail package) is responsible for validating and delivering the mail to
those recipients.

It has been previously noticed that one somewhat common VMS practice
can cause difficulties with mail: that of removing the home directory
of a user who is still in the VMS User Authorisation File.  (Apparently
this prevents logins whilst still maintaining accounting information in
the UAF.  Or something; I'm not a VMS guru by a long shot.)  The
Wollongong mail system apparently checks the validity of a mail
delivery address (the RCPT TO:<mailbox> line) during the SMTP
transaction by checking the UAF.  If a user is still in that file, it
OK's the destination mailbox and continues.  If the user is NOT in the
UAF, a reject message is instead returned, and the mail will be
returned to the sender as having one or more "recipient unknown"
problems.

After the list of recipients is negotiated, the mail message itself is
sent.  At the end of this DATA portion of the SMTP connection, the
Wollongong VMS software invokes the VMS mailer to deliver the actual
mail.  The SMTP connection is still open to the originating mailer (in
this case, sdcsvax's sendmail daemon), and will remain that way until
OK and QUIT transactions take place.  Ordinarily, the Wollongong
software delivers the mail to the user's mailbox file, and returns an
OK to the sender, who in turn QUITS the connection, and all is well.

However, if the recipients's home directory on the VMS system is
missing, the delivery fails, and an error code is returned.  Sendmail
then assumes that the mail wasn't delivered, since it never got the OK,
and requeues the message for delivery on the next queue run (about 20
minutes later under our circumstances), and the whole process repeats
until either the mail is successfully delivered to all validated
recipients, or until the message times out after 3 days (or someone
goes in and snuffs it).

Where this is a real pain is when you have a long list of recipients
and somewhere in the middle of it (or worse, near the end!) there is
one whose mailbox isn't available for delivery - if, for instance, his
home directory is missing.  Then what happens is that all the
recipients PREVIOUS to him have gotten the mail message delivered to
them, but sendmail gets an error back from the Wollongong VMS mailer,
and requeues the message to ALL the recipients again, so they'll get
another copy 20 minutes later.

There isn't any cure for this, except for Wollongong to make their
software smarter.  There's no provision in the SMTP specification to
allow the mail transport mechanism to accept a recipient in the earlier
part of the transaction, and later selectively reject it.  Obviously
one should not send messages to people who aren't there anymore, but
sometimes it is difficult to tell which are valid addresses when doing
massive bulk mailings.  Neither is it particularly intelligent to
return an error message to sendmail that applies to only one recipient
when the message isn't totally lost.  I guess sendmail is at fault here
too.  Maybe its the SMTP specification that's losing.

	Brian Kantor    UCSD Office of Academic Computing
			Academic Network Operations Group UCSD B-028,
			La Jolla, CA 92093 USA

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 18:26:00 EST
From:      Kevin_Crowston@XV.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   When to acknowledge SMTP messages

Message type: Message
Topic: SMTP
Text: 
Re: Message of 25 Feb 87 05:01 from MRC%PANDA@SUMEX-AIM.Stanford.EDU

> The server should NOT make the client wait while a message is
> being delivered...

I faced this issue when implementing our mail relay.  I decided that the
client SMTP would have to wait while the relay delivered the message.
Otherwise, the relay could acknowledge the message and then crash
or discover that the destination mail server was unable to take the message.
Either way, the mail goes on the floor, hardly desirable.  Acknowledgement
should mean that the message is really okay.

On the other hand,  I also get multiple copies of a lot of whole and partial
messages; it seems that some hosts are less patient than others...

Kevin Crowston
MIT Sloan School of Management

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 19:12:35 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: When to acknowledge SMTP messages

Kevin Crowston -

     Your relay should queue the message on its local disk and acknowledge
it once it is safely written.  That protects against the system crash
problem.  If the message cannot be accepted by the other end, then the
message should be returned to the sender via the return-path address.

     An SMTP server should NEVER block a client waiting for delivery.
It is STUPID and WRONG-HEADED to keep an SMTP connection open for ANY
period of time longer than is necessary to get the bits across and
acknowledged.

     The world isn't necessarily the Internet with no charges per packet
or time charges for a virtual circuit.  When time charges are a reality,
mail servers that block clients COST REAL MONEY.

     Sorry for flaming, but this really is an important concept.

-- Mark --
-------

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 19:38:41 EST
From:      geof@decwrl.DEC.COM@imagen.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: When to acknowledge SMTP messages


 >  > The server should NOT make the client wait while a message is
 >  > being delivered...
 >      
 >  I faced this issue when implementing our mail relay.  I decided that the
 >  client SMTP would have to wait while the relay delivered the message.
 >  Otherwise, the relay could acknowledge the message and then crash
 >  or discover that the destination mail server was unable to take the message.
 >  Either way, the mail goes on the floor, hardly desirable.  Acknowledgement
 >  should mean that the message is really okay.

I agree whole-heartedly.  The problem is with SMTP itself.  TCP mandates
that it is the client's responsibility to ensure that the remote client
is up.  In other words, TCP won't probe an idle connection (the old
"keep-alive" discussion), so the higher level protocol must do so if it
cares.  This behavior on TCP's part is necessary to cope with potentially
expensive network paths (e.g., a PTT network that bills by the packet),
so that quiescent TCP connections do not run up big bills.  If you're out of
the office for lunch, you don't want your telnet connection to send
packets around uselessly for an hour or more.  As in most cases, it
doesn't matter much when you're on an Ethernet, but it does in the more
general case.

In the case of SMTP, when a message is terminated with a ".CRLF", no
SMTP data may flow except the server's success/fail response.  Since
the TCP connection is quiescent during this interval, TCP cannot detect
a remote crash.  The only reasonable thing to do is to have SMTP set its
own death timer when it sends ".CRLF" and hope the message can be
delivered during that time interval.

The trouble is that there is no way to judge how long the SMTP death timer
should be.  Some machines deliver mail fast, others not so fast (mine
is just plain slow).  No matter what value you set for the death timer,
you lose some of the time.  And the way you lose is that mail to one type of
host is always lousy.

The ultimate answer would be to fix SMTP, so that the server could still
respond with "OK, I'm still here" messages while it was delivering the
mail.  Given all the SMTP hosts out there, this is probably not going to
happen.  Ad hoc solutions include:

   1. Have the server respond before the message is sent (bad, since messages
      can get dropped on the floor).

   2. Adjust the timeouts to try and accomodate every host you would
      reasonably connect to => every TCP implementation.  This is
      what we do now, and it doesn't work all the time.

   3. Find some random data for the message sender to periodically
      queue.  This would have the effect of taking the TCP connection
      out of its quiescent state, so that the TCP layer can detect
      a machine crash for you.  This works unless the problem is
      that the remote SMTP server is in a tight loop, with the remote
      TCP still healthy (that's a "software bug"-type situation that
      can be detected and fixed).

I favor [3].  Try this:

    When you send ".CRLF":
        set timer for how long you expect this to take (T)
        set timer for how long you are willing to hang (D >> T)
        set noops=0
        wait for input from server
    
    On TIMER T:
        send NOOP<CRLF> command to server
        noops = noops + 1
        set timer to T
        go back to waiting for input from server

    On INPUT:
        process success/fail message from SMTP SEND command
        while noops > 0 do
            read & discard command from server
            noops = noops - 1
            end

    On TIMER D:
        assume failure of message.

The idea is that by sending NOOP commands, the TCP layer will
probe the underlying connection for you.  Thus, the ultimate
timer, D, can be VERY long, since it detects bugs in the remote
SMTP, not random events.  The annoyance is that you have to
ignore enough responses to match each noop you sent (I guess
the other annoyance is that it is a miserable hack that should
be shot at sunrise...).

An obvious enhancement is to query the local TCP before sending
a NOOP -- it is not necessary to send anything unless the local
TCP is quiescent.  This is extremeley useful in the situation
where the SMTP connection is dribbling along at 1200 baud somewhere
and the REAL problem is that the message hasn't been TRANSMITTED yet.

The timer T should be long enough to give the other machine a
running shot at delivering the message in that time (say 1-5
minutes).

- Geof

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 19:47:02 EST
From:      jordan@UCBARPA.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: When to acknowledge SMTP messages

Kevin Crowston writes:

	I decided that the client SMTP would have to wait while the
	relay delivered the message.  Otherwise, the relay could
	acknowledge the message and then crash or discover that the
	destination mail server was unable to take the message.

Sendmail seems to handle this correctly, since "delivered" to that part
of the code means "placed in the queue" (i.e., wrote it to disk ... if
the machine then crashes, the daemon will pick up where it left off
since the queue file is still there) -- you can't acknowlege the
message as being sent before you have firm control of it.  That's what
lock-step is all about.  Once you have done that, if you find later
that you can't deliver it, it's up to the recipient SMTP process to
send it back to where it came from.  This can be handled
asynchronously.

/jordan

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Feb 87 12:30:40 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Excelan VMS and microMVS
Can anyone comment on the Excelan VMS and MicroVMS implementations?  Good?
Bad?  Plz reply directly to me so as not to flood the list with too much
unnecessary comments.
 
Thanks,
Hank
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 21:44:19 EST
From:      sy.Ken@CU20B.COLUMBIA.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: When to acknowledge SMTP messages


    > The server should NOT make the client wait while a message is
    > being delivered...

  I faced this issue when implementing our mail relay.  I decided that the
  client SMTP would have to wait while the relay delivered the message...

I think the furthest the acknowledgement process should go is essentially
"message received by this host and queued for delivery locally".  In so
many cases, there's often too much processing involved in delivering to the
final destination mailbox that the sending system should NOT have to wait
for all of this to go on.  I see the cases of local mailbox delivery and
mail forwarding as the same.  For example, host A wants to send to host C,
not on host A's network.  It must therefore forward through host B.  Should
host A have to wait while host B tries to forward the mail through all the
way to host C?  This case is clearly unreasonable.  The local delivery
process can often be just as unreasonable for a variety of reasons, and
thus, the mail should be stuffed into some local delivery queue (which
would presumably be a fast process), and actual local delivery can then
happen asynchronously with the SMTP dialog.  If there is some fatal case
where the mail cannot actually be delivered after being queued on the
target system for local delivery, then the entire message can be returned
to the sender by the mailer.  This is how the TOPS-20 mailer works, and it
seems like a fairly airtight procedure in practice as well as in theory.

/Ken
-------

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Feb-87 23:13:34 EST
From:      postel@bel.isi.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   GOSIP

Hello:

There was a message to this list a month ago about the GOSIP report, the
Government Open Systems Interconnection Procurement Specification.

It turns out that this is a matter that deserves our serious attention.

In general it is a well intention effort to come up with a plan to get
the US Government to acquire computer communication protocols that will
interoperate so that computers that need to exchange information can do
so.

Unfortunately, there are some aspects of the plan where good intentions
run ahead (on thin ice) of practical reality.  It is important that the
authors of the plan hear comments on it soon, in the next two weeks!
The authors i know of are in the CC field of this message.

The report has been coordinated with a large set of government staff
represeneting a large number of government agencies (many that have
nothing to do with computing research and development, but that do use
computers).  Please do not assume that this plan is someting that NBS
and DOD cooked up to do in IP/TCP.  In fact, the DOD people involved
are perhaps the most knowledgeable and reasonable.  A major problem is
that for most of the other representatives, what they know about protocols
(if anything) is what they read in Computerworld or Datamation.

So please find out more about the GOSIP report, and send comments to the
authors.  The activity is coordinated by the NBS so offline comments should
be sent to:

	GOSIP
	Institute for Computer Sciences and Technology
	National Bureau of Standards
	Gaithersburg, Maryland  20899

--jon.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Feb 87 16:00:28 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   MICOM-Interlan
For that matter can anyone comment on the MICOM-Interlan Tcp/Ip implementation
for VMS and microVMS?  Good Bad?  Once again, reply directly to me.
 
Thanks,
Hank
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 03:58:28 EST
From:      mrose@nrtc-gremlin.arpa.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: When to acknowledge SMTP messages

Hack.  Hack.  Hack.  Two things:

1.  As Jordan pointed out: as soon as the SMTP server queues the message for
    delivery (not actually delivers it), the server should send the success
    acknowledgement to the client.  Even if your host is single-threaded,
    the server can always deliver the mail *after* the SMTP connection is
    closed.

2.  Why hack SMTP?  I can find similar faults with interactions in FTP.
    And in just about any command/response application that you can run
    on top of TCP.  The correct solution is to add an *option* to TCP
    saying to use keep-alives.  Things like SMTP could use it, things like
    telnet (where a failure is obvious to any interactive user) don't have
    to use it.  With this solution, you only have to make a very small
    change to the way an application opens the network, instead of complicating
    the peer-to-peer protocol used by the application.  Keep it simple guys!

/mtr

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 04:05:25 EST
From:      MRC%PANDA@SUMEX-AIM.Stanford.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: When to acknowledge SMTP messages

A much better approach is for the SMTP server to queue the message on
its local disk and acknowledge immediately.  The delivery can be done
by an asynchronous process.  Unless your system is in real bad shape,
it shouldn't take any time at all to write a file on the disk.

It is much better to cure the disease (SMTP servers taking an
indeterminate amount of time to respond) than it is to mask the
symptoms.
-------

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 08:22:22 EST
From:      mo@seismo.CSS.GOV.UUCP
To:        mod.protocols.tcp-ip
Subject:   STMP and waiting for Godot

All this discussion about when and why one does what one does with SMTP
leads me to reiterate a viewpoint discussed long ago during the 822 MailWarz.

In my humble opinion,
if a mail system isn't reliable, it isn't a mail system.
This applies to local mail, SMTP, UUCP, X.400, BITNET, or whatever.
(I think I offended everyone!)
So...

An extremely important notion in the design of mail systems is the "transfer
of responsibility" for a message.  In my view of the world,
when one mail agent acknowledges a transfer to another, the acknowledging
againt isn't required to specify exactly what that means over and above
the fact that the new agent in charge of the message
is obligated to either (1) deliver the message
to the recipient, (2) reliably transfer responsibility to another
mail agent or (3) start returning the message to the originator,
along with an explanation as two why (1) or (2) wasn't possible.
I say "start returning", because the returned mail is in fact contained
in a new message, originated by the mail agent, and is handled as any
other message - ie, mail agents handing off responsibility for a message
until it is delivered to the recipient (whatever that means).

So, as Mark Crispin points out, to concienciously accept responsibility,
an agent must have committed the message to some (fairly) robust storage
before acknowledging it, lest it be lost in a crash.  Whatever else
must be done with the message to accomplish (1), (2), or regretably (3)
can be done after the copy is firmly in hand (disk) and the transfer
of responsibility has happened.

I think this model of transferring responsibility (and only implicitly
the message) is more useful because when one transfers only messages,
it isn't clear who is liable for what in what circumstances.  If one
is transferring responsibility for safe conduct of an object, it 
becomes much clearer what one's alternatives actually are.  Further,
I think this has interesting impacts on protocol design.  Anyway...

	I hope this sheds some light on things,
		-Mike O'Dell

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 11:56:53 EST
From:      braden@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Specs on IP Routers

There is an initial draft of a spec on Internet gateways, or as you call
them, routers; it is RFC985.  We are actively working on a revised and
extended version of this spec; stay tuned!

Bob Braden

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 12:00:44 EST
From:      bruce@THINK.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   HDH <-> X.25

The HDH/X.25 problem I asked about several days ago has been fixed, on
the ARPANET at least.  The PSNs were sending larger-than-legal frames
to the packet mode HDH interface, causing it to hang.

There was a PSN patch for this problem which was known about several
months ago, but for some reason was not installed arpanet-wide until
this morning.  Thanks to those who helped with this.

--bruce

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 12:04:18 EST
From:      AI.CLIVE@MCC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Another aspect of SMTP timeouts

The large number of recent messages about SMTP clients waiting for servers
don't seem to have mentioned a related problem which is just as annoying:
How long should an SMTP server process wait for a client before giving up?

For many weeks our system constantly had two or three active server
processes connected to a certain host.  Investigation showed that the
client host would stop sending data after the MAIL FROM: command, and our
SMTP server would give up and close the connection 5 minutes later.  A
minute or two later, the client host would open another connection and try
again, etc. etc.  I finally had to increase the server timeout to FIFTEEN
minutes, and the client was finally able to get the message through.

People have suggested several reasons why a server might be delayed in
responding to a client; but I see no excuse for a client to be so slow
about it.  The host in question was an overloaded 750 running Unix.  I
don't know many more details, but I'm told that the Unix mailer actually
validates each address in the header after the connection is already open,
and that furthermore this validation is repeated during each connection to
the various hosts for which the message is destined.  If a message has a
couple of dozen addressees, this adds up to quite a bit of time.

This sounds unbelievable to me, and I hope that Unix folks take the time to
tell me that my info is wrong, or that the situation will soon be fixed.
Mailers should get all of their validation, etc., done BEFORE opening any
connection.  Once the connection is open they should state their business
quickly, expect a quick response, and then leave.  A network connection
is a valuable resource, and my system can't afford to tie up several
in an idle state waiting for remote hosts to spin their wheels.

Clive
-------

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 13:41:34 EST
From:      dms@HERMES.AI.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   When to acknowledge SMTP messages


   Date: Thu, 26 Feb 87 16:47:02 PST
   From: jordan@ucbarpa.berkeley.edu (Jordan Hayes)
   Organization: Experimental Computer Facility (XCF), UC Berkeley

   Kevin Crowston writes:

	   I decided that the client SMTP would have to wait while the
	   relay delivered the message.  Otherwise, the relay could
	   acknowledge the message and then crash or discover that the
	   destination mail server was unable to take the message.

   Sendmail seems to handle this correctly, since "delivered" to that part
   of the code means "placed in the queue" (i.e., wrote it to disk ... if
   the machine then crashes, the daemon will pick up where it left off
   since the queue file is still there) -- you can't acknowlege the
   message as being sent before you have firm control of it.  That's what
   lock-step is all about.  Once you have done that, if you find later
   that you can't deliver it, it's up to the recipient SMTP process to
   send it back to where it came from.  This can be handled
   asynchronously.

   /jordan

Actually, sendmail doesn't handle this completely correctly. Before
sendmail queue's up a message, and gives the acknowledgment back to
the sender, it attempts to expand every address in a mailing list.
This expansion can take a long time, since it means a call to the
resolver to qualify host names. So, messages sent to large mailing
lists take a long time to get queued up. What sendmail should be doing
is writing out a very simple queue file with the un-expanded
receipients. The background delivery process should do the expansion
the first time it comes across an un-expanded address.

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 13:52:17 EST
From:      randy@june.cs.washington.edu@bcsaic.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: bcsaic!randy
From: randy@bcsaic.UUCP (Randy Groves)
Newsgroups: comp.sys.ibm.pc,mod.protocols.tcp-ip,mod.computers.ibm-pc
Subject: TCP-IP implementations for the PC anyone??
Keywords: tcp-ip pc
Message-ID: <461@bcsaic.UUCP>
Date: 27 Feb 87 18:52:16 GMT
Organization: Boeing Computer Services ATC, Seattle
Lines: 17

We have a requirement for network connections between IBM PC's and various
mainframe/workstations, all of which speak either TCP or DECnet.  I need
to find out what is available - either commercial or PD in either realm.

So if you know of or use a TCP or DECnet implementation on PC's - using
Ethernet or some other medium, please let me know by email.  I need
basic file transfer at the minimum, some sort of ipc or telnet capability
would be nice if available.

Thanks much.

-randy groves
Boeing Advanced Technology Center

UUCP:	..!uw-beaver!uw-june!bcsaic!randy     USNail: Boeing Computer Services
CSNET:	randy@boeing.com		              PO Box 24346 M/S 7L-44
VOICE:	(206)865-3212				      Seattle, WA   98124

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Feb-87 18:19:50 EST
From:      jkrey@AKAMAI.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Internet Network Number/AS Number Assignment Contact Change


As of March 1st, 1987, the Network Information Center (NIC) at SRI will
be taking over ALL assignments of network numbers and autonomous system 
numbers (AS) for the Internet.

Anyone having questions about applications, network number/AS number
assignments, or further information, should contact the Hostmaster at 
the NIC (<HOSTMASTER@SRI-NIC.ARPA>) or call 1-800-235-3155.

Joyce Reynolds and Jon Postel

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Feb-87 20:18:48 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Another aspect of SMTP timeouts

Sorry, but your diagnosis is quite correct.  We modified sendmail a
year or so ago to map nicknames into primary host names.  We found
that suddenly connections were timing out.  Turns out the code to
process headers was invoked after the connection was opened.  My
sensibilities were badly offended, but I found I could make things
work by moving our host table to a dbm format.  This speeded things up
enough that the other end wouldn't time out.  Now that we have moved
to the domain system, it is quite possible that the problem has
returned.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Feb-87 20:39:03 EST
From:      minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: xerox -> 4.3bsd telnet

> We recently installed a xerox 1186 (dandytiger?) running koto
> release 2.0.  Telneting from the 1186 to our vax 780 running
> 4.3bsd hangs, apparently because the 1186 doesn't respond to
> the vax telnet server's "do terminal-type" negotiation.  The
> 4.3bsd telnet server waits in a loop for the "will/won't terminal-type"
> response, processing options, but not starting a login process.
> That seems unforgiving (although seemingly legal) from 4.3bsd.
 ...
>					Or, is 4.3bsd wrong
> to "hang" waiting for the "will/won't terminal-type" response?
> 
> Thanks,
> 
> Ron Stanonik
> stanonik@nprdc.arpa
> 
> ps.  The 1186 also seems to violate the rfcs by sending the
> "terminal-type is" subnegotiation without first receiving
> a "terminal send".  Or maybe it thinks that is a suitable
> response to "do terminal-type"?

I wrote some of the code in the 4.3 telnet server.
I didn't want to start up the login process until I got a reply
to the terminal type negotiation, since a positive reply would
allow me to set up the terminal type in the login processes
environment.  In an engineering sense, I could have said
"if no answer within N seconds, skip the terminal type negoitiation".
I didn't do that.  In a more perfect world, I probably would have.

Now, as for your "1186", if it listens to "do terminal type"
by replying "terminal type is", then it is out of spec, and you
should ask your vendor for a fix.  RFC930 is quite specific on
this point (as well it should be).

In summary, the 4.3 implementation is legal and even "reasonable"; it
is not as robust as could be.  Your description of the "1186"'s
behaviour leads me to believe that it is not implementing the protocol
correctly.


Yours,

Greg Minshall

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Feb-87 22:43:45 EST
From:      farber@HUEY.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Delta-T Paper

The correct source is Richard Hamming when he was at Bell Labs and
said Mathemeticians stand on each other shoulders (Gauss I think) while
computer scientists stand on each others toes.

Dave

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Mar-87 00:41:00 EST
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords


    Date:  18 January 1987 15:57 est
    From:  The Matt Crawford of net.* <matt at ODDJOB.UCHICAGO.EDU>
    Subject:  Re: secure replacements for passwords

    J. Spencer Love writes:
    ) I don't know about your TCP, but the Multics TCP will send a RST
    ) immediately if it receives a packet with an ACK that is too high.  I
    ) believe that this is clearly spelled out in the specification, but I am
    ) at home and don't have the specification handy.

    Nope, RFC-793 says "If the ACK acks something not yet sent
    (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and
    return.

Thank you for pointing this out.  I'm sorry that this reply is so
delayed.

The Multics TCP does, in fact, behave as I claimed.  I have examined
RFC-793, and the sentence which Matt Crawford quoted is on page 72 (page
2-256 of the DDN PROTOCOL HANDBOOK).  This deals with the ESTABLISHED
state.  In the pre-ESTABLISHED states (LISTEN, SYN-SENT and
SYN-RECEIVED), the specification directs the implementor to form a RST
packet based on the invalid acknowledgement.  Thus, the Multics
implementation's behavior is conformant until the connection is
established, and deviant thereafter.

Does anyone know what the specifiers had in mind when they made this
distinction?  The rest of this message attempts to explain my reasons
for believing that the specification is wrong here and should be
changed.

If someone attempts to spoof the connection, they can do so by
monitoring the connection and inserting a packet.  This packet might
contain commands (via the TELNET server), spurious mail, or faked output
(back to the user TELNET).  Because packets routinely come from gateways
which are not the IP header source, it is difficult to detect this
spoofing by examining the lower layer's packet source.

There are two cases.  In the "hard" case, the spoofer has corrupted
network routing, so that no packets are exchanged between the original
connection endpoints.  The spoofer can insert itself into the
connection, completely concealing its presence, or permit one side of
the connection to time out, replacing it to the other side of the
connection.  Hopefully, this type of spoofing can be prevented by other
means.

In the "easy" case, the connection routing is not disrupted.  The bogus
packet is merely inserted into the stream.  The receiver of the bogus
packet will issue an acknowledgement which will get back to the other
end of the connection.  If we are lucky, this packet will appear to
acknowledge something which hasn't yet been sent.  If it *has* been
sent, then the chance of the bogus packet's being accepted is reduced,
unless routing has also been corrupted.  If routing has been corrupted
in the direction that the bogus packet's acknowledgement will travel,
then this is effectively the same as the "hard" case.

I can't think of a situation where a "precognitive" acknowledgement is
valid.  If one arrives, it indicates either that a spoof attempt has
been made, or that a packet has long outlived its TTL and emerged from
some network backwater like some kind of glacier-preserved SF creature.
The chance that such an anachronism will also pass the sequence number
check is hopefully small, but certain operating systems which we all
know are very repetitious about selecting port and sequence numbers.

The receiver of the precognitive acknowledgement should send a RST
packet.  Ideally, it should also refrain from sending data up to the
precognition point for awhile (some function of RTT and TTL), but that
is probably too much to ask.  It should also log the precognitive ACK as
a possible spoof attempt.

If the precognitive ACK really emerged from the glacier, then (ignoring
race conditions), the RST packet which it elicits will fail the sequence
number test at the other end of the connection and is thus harmless.  If
routing has been corrupted in the direction the RST travels, at least
the spoof has been detected and logged at one end so that
troubleshooting can find it later.  If the RST gets through, it will
abort the spoofed connection and hopefully minimize the damage.  If the
RST packet carries an "explanation" in its otherwise unused data field,
then this also can be logged at the receiving end so that both ends of
the connection have a record of the spoof.

The likelihood of having normal service clobbered by this RST is low.
The likelihood of a spoof is hard to estimate, but the protocol should
act to limit, as much as possible, the effects of spoofing, and to
detect such attempts, especially when no extra work is involved.

With this in mind, I don't plan to change Multics to conform to the
specification in this area, although I would be interested in and would
act upon a convincing refutation.
                                        -- Spencer Love

END OF DOCUMENT