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