|
|
ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for April 1986 (171 messages, 71954 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Tue, 1 Apr 86 08:24 EST From: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA To: tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Concerning unused options in IP packets.
I'm just learning tcp/ip myself. In reading rfc 791, I found the
following general statement in section 3.2:
"In general an [IP] implementation must be conservative in its
sending behavior, and liberal in its receiving behavior."
Concerning assumptions about IP packet option formats this seems
like a VERY good idea. To protect one's own system, one should hope for
good input but expect problems with incoming packets. In general I've
found this to be the best way with most software. Yes it's more work
and on some systems it can be very difficult. However, covering your
tail pointer is usually a good idea. It can be very embarrassing to
have your wonderful, totally cosmic piece of software crash in public.
It's even more embarrassing when a real-time system like network goes
down because you drop packets on the floor and then have to get a broom
and a bucket to clean things up. At the speeds and traffic level of
some parts of the network, the mess can get really big FAST.
I don't know about anyone else but I don't think I'd assume
anything about what options look like in a packet. We all know what
happens when assumptions are made.
Chris Johnson
Sr System Programmer
Northeastern University
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Tue, 1 Apr 86 9:10:13 EST From: Terry Slattery <tcs@USNA.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: host.txt
I use host.txt frequently to look up hosts which I know to be on the net and don't know their official names (or even a hit of their name other than the organization name). I have gone as far as to create a simple script to match patterns in the host tables so that users here can quickly look to see if they can find out the name of the host(s) at other sites on DDN. If (when?) host.txt goes away, I would hope that there would be a counterpart to 'whois' for polling the servers about potential host names. Pattern matching is important because I also use this script to look up all hosts attached to particular sub-nets or imps. It helps me get an idea of the route my data is or will be taking to get to a particular host. -tcs
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 1 Apr 86 16:37:25 EST From: Mike Muuss <mike@BRL.ARPA> To: Murray.pa@xerox.com Cc: TCP-IP@sri-nic.arpa, Murray.pa@xerox.com, JLarson.pa@xerox.com Subject: Re: Anybody normally send packets with unused options?
I recall a comment from the Cray TCP people that they use empty option bytes to word-align their data areas in the packets. I suspect that on machines with a strong word-alignment preference, this practice will be increasingly popular. -Mike
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 86 19:55 PST From: Jeff Makey <Makey@LOGICON.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: Makey@LOGICON.ARPA Subject: ICMP Redirect Wars
Every now and then, two or three of the ARPANET<->MILNET gateways will
get into an ICMP Redirect argument over who should be handling one of
my connections. Below is the latest example of this behavior, taken
from my April 1 TCP/IP daemon log (this happened before April Fools
day, too).
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:36)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:38)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:43)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:44)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:45)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:49)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:53)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:57)
Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:59)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:12:02)
Redirect 10.0.0.44 (code 0) to 26.0.0.104 (from 26.2.0.73 at 16:16:05)
Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.0.0.104 at 16:16:06)
Notes: All times are Pacific Standard Time (HH:MM:SS).
Code 0 means "Redirect datagrams for the Network" [RFC 792].
10.0.0.44 is XX.LCS.MIT.EDU.
26.2.0.73 is SRI-MILNET-GW.ARPA (my host's assigned ARPANET<->
MILNET gateway [DDN Mgt Bulletin #23]).
26.2.0.49 is BBN-MILNET-GW.ARPA.
26.0.0.104 is DCEC-MILNET-GW.ARPA.
It was a TCP/SMTP connection sending from XX.LCS.MIT.EDU to
LOGICON.ARPA (26.2.0.3). I don't know exactly when the
connection was established, but we received the SMTP DATA
command at 16:12:15 and the last of 10868 bytes trickled
in at 16:17:07 (for an average of 37.2 bytes per second).
(The piece of mail was Arms-Discussion digest V6 #69.)
An occasional redirect is fine, but this whipsawing back and forth
can't be good for anybody (due to the ICMP overhead). Is this sort of
behavior just a symptom of the poor ARPANET<->MILNET performance or
does it contribute to the problem?
:: Jeff Makey
Makey@LOGICON.ARPA
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Apr 1986 22:16:48 EST From: MILLS@USC-ISID.ARPA To: mike@BRL.ARPA, Murray.pa@XEROX.COM Cc: TCP-IP@SRI-NIC.ARPA, JLarson.pa@XEROX.COM, MILLS@USC-ISID.ARPA Subject: Re: Anybody normally send packets with unused options?
In response to the message sent Tue, 1 Apr 86 16:37:25 EST from mike@BRL.ARPA Mike, Cray may save a nanosecond or two when constructing a packet to send, but it sure doesn't help when receiving a packet. The practice may be getting popular as you say, but it's broken. Our Internet Toolbook should include a chapter on how to compute checksums in wonderfully wierd ways for TOPS-20s, Multices, Univax and Borroughs, not to mention a 7090 and anything else with oddly sized words. Dave -------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 1986 07:55:53 PST From: Dan Lynch <LYNCH@USC-ISIB.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: LYNCH@USC-ISIB.ARPA Subject: Diabolically Execrable?
Ddoes anyone out there think that the recent performance of Milnet/Arpanet is simply a test of the robustness of the protocols involved?/ If so, then you could tell the authorities that the data arrived intact and in order, but the need for it vanished before it arrived. Dan PS. It only took me 30 minutes to compose this, Noel. Maybe things are improving??? -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: FTP protocol violations
Folks, 4.2BSD replies with 200 to DELE rather than 250. If being permissive about what one accepts means accepting this, should I make my implementation ignore the second two digits of positive responses to simple model commands? I can't see taking too and 250 and no other 2xy's.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 1986 16:23-PST From: STJOHNS@SRI-NIC.ARPA To: DCP@SCRC-QUABBIN.ARPA Cc: romkey@MIT-BORAX.ARPA, Margulies@SCRC-YUKON.ARPA tcp-ip@SRI-NIC.ARPA Subject: Re: FTP protocol violations
The robustness principle says that you accept anything that works, but you do the right thing for anything you put out. John is perfectly correct in accepting wierd responses if he can get it to work. On the other hand, the 4.2 implementation is WRONG and should be fixed post haste. For those of you on the MILNET side of the house, there will eventually be a suite of protocl certifiers including FTP. (Please, no inquiries, I've told you all I know) Each milnet system will eventually have to toe the line. Mike
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) To: Margulies@SCRC-YUKON.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: FTP protocol violations
Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA> If being permissive about what one accepts means accepting this, should I make my implementation ignore the second two digits of positive responses to simple model commands? I can't see taking too and 250 and no other 2xy's. That's the way my IBM PC FTP does it. The command state machine is just driven by the first digit. The other two digits can be used to get more information, but unless I've missed something somewhere, you can safely ignore them in deciding whether or not a command succeeded, or what to do next. - john romkey ftp software
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 Apr 86 17:06 EST From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA> To: John Romkey <romkey@BORAX.LCS.MIT.EDU>, Margulies@SCRC-YUKON.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: FTP protocol violations
Date: Wed, 2 Apr 86 14:15:37 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 09:36 EST
From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
If being permissive about what one accepts means accepting this, should
I make my implementation ignore the second two digits of positive
responses to simple model commands? I can't see taking too and 250 and
no other 2xy's.
That's the way my IBM PC FTP does it. The command state machine is
just driven by the first digit. The other two digits can be used to
get more information, but unless I've missed something somewhere,
you can safely ignore them in deciding whether or not a command
succeeded, or what to do next.
- john romkey
ftp software
Wait a minute. A spec is a spec. What's the point of the two digits if
(a) some hosts send the wrong ones, and (b) some hosts don't bother to
look at them. If the spec said you could be lazy, then it would be OK.
If the spec doesn't, an implementation is INCORRECT if it sends the
wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
more than what the spec says.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 Apr 86 17:37:01 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) To: DCP@SCRC-QUABBIN.ARPA Cc: Margulies@SCRC-YUKON.ARPA, tcp-ip@SRI-NIC.ARPA Subject: more FTP protocol violations
Date: Wed, 2 Apr 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Wed, 2 Apr 86 14:15:37 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 09:36 EST
From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
.....
.....
Wait a minute. A spec is a spec. What's the point of the two digits if
(a) some hosts send the wrong ones, and (b) some hosts don't bother to
look at them. If the spec said you could be lazy, then it would be OK.
If the spec doesn't, an implementation is INCORRECT if it sends the
wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
more than what the spec says.
I probably should've just done this the first time, but I had to go
reread the spec to be sure. From RFC 959, last paragraph of page 36:
"The three digits of the reply each have a special significance.
This is intended to allow a range of very simple to very
sophisticated responses by the user-process. The first digit
denotes whether the response is good, bad or incomplete.
(Referring to the state diagram), an unsophisticated user-process
will be able to determine its next action (proceed as planned,
redo, retrench, etc.) by simply examining this first digit. A
user-process that wants to know approximately what kind of error
occurred (e.g. file system error, command syntax error) may
examine the second digit, reserving the third digit for the finest
gradation of information (e.g., RNTO command without a preceding
RNFR)."
And Section 6 presents some simple state machines for commands, using
only the first digit of the code to drive them. So we can be lazy if
we want to.
It makes sense to me to have an error indication (first digit) and
then a more specific error code (second digit), but it doesn't seem to
me that we should really have to worry about "what kind of success"
happened when there was no error, which is what the original question
was about (4.2 returning a strange success code). So I think most user
implementations can probably ignore the second and third digits in the
case of success.
Of course, if there is a "standard" response (250) to send in the case of
success, a server should probably send that instead of something else
that's similar but not quite the same (200). Appendix II of RFC959
says that the correct success response to a DELE is 250.
- john
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 Apr 86 17:44 EST From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA> To: John Romkey <romkey@BORAX.LCS.MIT.EDU>, DCP@SCRC-QUABBIN.ARPA Cc: Margulies@SCRC-YUKON.ARPA, tcp-ip@SRI-NIC.ARPA Subject: more FTP protocol violations
Date: Wed, 2 Apr 86 17:37:01 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Wed, 2 Apr 86 14:15:37 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 09:36 EST
From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
.....
.....
Wait a minute. A spec is a spec. What's the point of the two digits if
(a) some hosts send the wrong ones, and (b) some hosts don't bother to
look at them. If the spec said you could be lazy, then it would be OK.
If the spec doesn't, an implementation is INCORRECT if it sends the
wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
more than what the spec says.
I probably should've just done this the first time, but I had to go
reread the spec to be sure. From RFC 959, last paragraph of page 36:
"The three digits of the reply each have a special significance.
This is intended to allow a range of very simple to very
sophisticated responses by the user-process. The first digit
denotes whether the response is good, bad or incomplete.
(Referring to the state diagram), an unsophisticated user-process
will be able to determine its next action (proceed as planned,
redo, retrench, etc.) by simply examining this first digit. A
user-process that wants to know approximately what kind of error
occurred (e.g. file system error, command syntax error) may
examine the second digit, reserving the third digit for the finest
gradation of information (e.g., RNTO command without a preceding
RNFR)."
And Section 6 presents some simple state machines for commands, using
only the first digit of the code to drive them. So we can be lazy if
we want to.
It makes sense to me to have an error indication (first digit) and
then a more specific error code (second digit), but it doesn't seem to
me that we should really have to worry about "what kind of success"
happened when there was no error, which is what the original question
was about (4.2 returning a strange success code). So I think most user
implementations can probably ignore the second and third digits in the
case of success.
OK, that takes care of the user end; user ends are allowed to be lazy.
Of course, if there is a "standard" response (250) to send in the case of
success, a server should probably send that instead of something else
that's similar but not quite the same (200). Appendix II of RFC959
says that the correct success response to a DELE is 250.
Several (all?) Unix server implementations send 200. This is NOT the
correct response, and I think a user program that does look at all three
digits is allowed to consider this a protocol violation.
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Apr 86 07:29 EST From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA> To: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>, John Romkey <romkey@BORAX.LCS.MIT.EDU> Cc: tcp-ip@SRI-NIC.ARPA Subject: FTP protocol violations
Date: Wed, 2 Apr 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Wed, 2 Apr 86 14:15:37 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 09:36 EST
From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
If being permissive about what one accepts means accepting this, should
I make my implementation ignore the second two digits of positive
responses to simple model commands? I can't see taking too and 250 and
no other 2xy's.
That's the way my IBM PC FTP does it. The command state machine is
just driven by the first digit. The other two digits can be used to
get more information, but unless I've missed something somewhere,
you can safely ignore them in deciding whether or not a command
succeeded, or what to do next.
- john romkey
ftp software
Wait a minute. A spec is a spec. What's the point of the two digits if
(a) some hosts send the wrong ones, and (b) some hosts don't bother to
look at them. If the spec said you could be lazy, then it would be OK.
If the spec doesn't, an implementation is INCORRECT if it sends the
wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
more than what the spec says.
I would point out that the general princible: `be precise in what you
send, be forgiving in what you receive' has been stated many times for
the internet protocol set. FTP, however, nowhere says that the
implication of this is to just look at the first digit. What are the
chances of a clarification from on-high?
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Apr 86 07:48 EST From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA> To: John Romkey <romkey@BORAX.LCS.MIT.EDU>, DCP@SCRC-QUABBIN.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: more FTP protocol violations
Date: Wed, 2 Apr 86 17:37:01 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Wed, 2 Apr 86 14:15:37 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 09:36 EST
From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
.....
.....
Wait a minute. A spec is a spec. What's the point of the two digits if
(a) some hosts send the wrong ones, and (b) some hosts don't bother to
look at them. If the spec said you could be lazy, then it would be OK.
If the spec doesn't, an implementation is INCORRECT if it sends the
wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
more than what the spec says.
I probably should've just done this the first time, but I had to go
reread the spec to be sure. From RFC 959, last paragraph of page 36:
"The three digits of the reply each have a special significance.
This is intended to allow a range of very simple to very
sophisticated responses by the user-process. The first digit
denotes whether the response is good, bad or incomplete.
(Referring to the state diagram), an unsophisticated user-process
will be able to determine its next action (proceed as planned,
redo, retrench, etc.) by simply examining this first digit. A
user-process that wants to know approximately what kind of error
occurred (e.g. file system error, command syntax error) may
examine the second digit, reserving the third digit for the finest
gradation of information (e.g., RNTO command without a preceding
RNFR)."
And Section 6 presents some simple state machines for commands, using
only the first digit of the code to drive them. So we can be lazy if
we want to.
It makes sense to me to have an error indication (first digit) and
then a more specific error code (second digit), but it doesn't seem to
me that we should really have to worry about "what kind of success"
happened when there was no error, which is what the original question
was about (4.2 returning a strange success code). So I think most user
implementations can probably ignore the second and third digits in the
case of success.
Of course, if there is a "standard" response (250) to send in the case of
success, a server should probably send that instead of something else
that's similar but not quite the same (200). Appendix II of RFC959
says that the correct success response to a DELE is 250.
- john
I wish that someone at the NIC would mark old RFC files old. I was
reading 765 ...
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Apr 86 07:50 EST From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA> To: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>, John Romkey <romkey@BORAX.LCS.MIT.EDU> Cc: tcp-ip@SRI-NIC.ARPA Subject: more FTP protocol violations
Date: Wed, 2 Apr 86 17:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Wed, 2 Apr 86 17:37:01 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 17:06 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Wed, 2 Apr 86 14:15:37 est
From: romkey@BORAX.LCS.MIT.EDU (John Romkey)
Date: Wed, 2 Apr 86 09:36 EST
From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
.....
.....
Wait a minute. A spec is a spec. What's the point of the two digits if
(a) some hosts send the wrong ones, and (b) some hosts don't bother to
look at them. If the spec said you could be lazy, then it would be OK.
If the spec doesn't, an implementation is INCORRECT if it sends the
wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
more than what the spec says.
I probably should've just done this the first time, but I had to go
reread the spec to be sure. From RFC 959, last paragraph of page 36:
"The three digits of the reply each have a special significance.
This is intended to allow a range of very simple to very
sophisticated responses by the user-process. The first digit
denotes whether the response is good, bad or incomplete.
(Referring to the state diagram), an unsophisticated user-process
will be able to determine its next action (proceed as planned,
redo, retrench, etc.) by simply examining this first digit. A
user-process that wants to know approximately what kind of error
occurred (e.g. file system error, command syntax error) may
examine the second digit, reserving the third digit for the finest
gradation of information (e.g., RNTO command without a preceding
RNFR)."
And Section 6 presents some simple state machines for commands, using
only the first digit of the code to drive them. So we can be lazy if
we want to.
It makes sense to me to have an error indication (first digit) and
then a more specific error code (second digit), but it doesn't seem to
me that we should really have to worry about "what kind of success"
happened when there was no error, which is what the original question
was about (4.2 returning a strange success code). So I think most user
implementations can probably ignore the second and third digits in the
case of success.
OK, that takes care of the user end; user ends are allowed to be lazy.
Of course, if there is a "standard" response (250) to send in the case of
success, a server should probably send that instead of something else
that's similar but not quite the same (200). Appendix II of RFC959
says that the correct success response to a DELE is 250.
Several (all?) Unix server implementations send 200. This is NOT the
correct response, and I think a user program that does look at all three
digits is allowed to consider this a protocol violation.
I disagree. The paragraph above says clearly that the basic response
semantics are implied by the first digit. It seems to me that the spec
should be revised to state that for success the later two digits are
unimportant.
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Apr 86 11:29:18 PST From: gds@sri-spam.ARPA (Greg Skinner) To: tcp-ip@sri-nic.ARPA Subject: Re: more FTP protocol violations
I don't have a copy of RFC959 handy, but here's an interesting paragraph
from RFC765 on the sequencing of commands and replies.
The table below lists alternative success and failure replies for
each command. These must be *strictly* (emphasis mine) adhered to; a
server may substitute text in the replies, but the meaning and action
implied by the code numbers and by the specific command reply
sequence cannot be altered.
And, in the sequence for DELE
DELE, CWD
250
450, 550
500, 501, 502, 421, 530
So it would seem (at least to implementors of RFC765 FTP) that the
burden of protocol correctness is on the server end. If I'm not
mistaken 4.2bsd FTP was written sometime afterwards with all the X
commands, which may account for the fact that it didn't conform to
RFC765.
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Several (all?) Unix server implementations send 200. This is NOT the
correct response, and I think a user program that does look at all three
digits is allowed to consider this a protocol violation.
Well, not all. I wrote an FTP server for a pdp11 v6 Unix once that
returned 250 for a successful delete. RFC765 seems to suggest that a
user FTP implement a FSM to interpret server replies, rather than match
on the replies themselves. Considering the fact that the requested
action is completed, independent of whether or not the response from the
DELE indicates so, it seems to be a bit nitpicky to require an exact
interpretation of the successful reply to a DELE, and also bothersome
for a user FTP to match exactly on its response. (Does anyone out there
actually examine for the grade of success?) But, of course, one should
be conservative in what one sends, etc.
--gregbo
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Thu 3 Apr 86 12:18:31-PST From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA> To: Margulies@SCRC-YUKON.ARPA Cc: romkey@MIT-BORAX.ARPA, DCP@SCRC-QUABBIN.ARPA, tcp-ip@SRI-NIC.ARPA, OLE@SRI-NIC.ARPA Subject: Re: more FTP protocol violations
Folks, The way to find the current version of any given RFC is to look in [SRI-NIC.ARPA]RFC:RFC-INDEX.TXT. In this file you will find the phrase: "Obsoletes RFC xxx" in the entry for the new one. I'll look into making this a two-way street so that RFC-765 would be marked "Obsoleted by RFC-959". Cheers, Ole -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Apr 86 09:59:36 EST From: Chris Torek <chris@gyre.umd.edu> To: DCP@scrc-quabbin.ARPA, Margulies@scrc-yukon.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: FTP protocol violations
Instead of complaining about the broken 4.x ftp server, I thought
it more useful to provide the fix. Here it is. Feel free to give
it to anyone whose server is still wrong.
Chris
RCS file: RCS/ftpd.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** /tmp/,RCSt1003149 Thu Apr 3 09:58:20 1986
--- /tmp/,RCSt2003149 Thu Apr 3 09:58:23 1986
***************
*** 559,565 ****
ack(s)
char *s;
{
! reply(200, "%s command okay.", s);
}
nack(s)
--- 559,565 ----
ack(s)
char *s;
{
! reply(250, "%s command okay.", s);
}
nack(s)
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1986 1406-PST (Thursday) From: johnsson@decwrl.DEC.COM (Richard Johnsson) To: tcp-ip@sri-nic.ARPA Subject: Core gateway slot problem
Has the problem of running out of Core gateway slots for connected networks suddenly gotten worse? Our network (128.45.0) seems to be going in and out (mostly out today) although our EGP process has been running continuously for the last three days. In the past my experience has been that once we got a slot we kept it until our gateway crashed. Richard
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1986 14:45-PST From: Rafael Bracho <spar!rxb@decwrl.dec.com> To: tcp-ip@ucbvax.berkeley.edu Subject: Please post in tcp-ip groups
Could you please post this message? Thanks.
===============
Subject: Arpanet/Ethernet gateway needed.
Reply-To: rxb@spar.UUCP (Rafael Bracho)
Distribution: net
Organization: Schlumberger Palo Alto Research
Keywords: tcp-ip, arpanet, gateways, HDH, 1822-J
I need some advise from arpanet wizards:
We just got our arpanet port assigned and are in the process of putting
together an arpanet/ethernet gateway. We have an HDH port (1822-J) which
pretty much limits us to the ACC IF-11/HDH board (is this correct?), a Unibus
board with HDH normally downloaded into it. We'd like something with
reasonable performance, we are getting 56kb DDS between our computer room and
the IMP.
Could anyone tell me what is the hardware I should buy? Which software can I
get to run on it? Is there anyone out in net-land that has an HDH port and
an arpanet/ethernet gateway?
Help is most appreciated.
Rafael Bracho
Schlumberger Palo Alto Research
415-496-4644
BRACHO@SRI-KL.ARPA
...{decwrl,hplabs}!spar!rxb
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 86 16:33:00 PST From: <gary@acc.arpa> To: "garry%cadif-oak" <garry%cadif-oak@cornell> Cc: tcp-ip@sri-nic Subject: tcp for AT&T
Garry, Wollongong has a contract with AT&T IS to supply TCP/IP for all levels of 3B's. This is bing coordinated by Computer Systems Division in Lisle. AT&T plans to offer the package as a supported product from them. ACC has a contract also with AT&T to supply 3B - 1822 interfaces for all of the 3B's. We have delivered the initial prototype units to AT&T and will be supplying the production units this month. Our development plans call for supporting a DDN X.25 interface sometime in the future for the 3B's as well. Please contact me direct about your specific application. Email: gary@ACC.ARPA Telephone: 805-963-9431 Regards, Gary Krall ------
-----------[000021][next][prev][last][first]----------------------------------------------------
Date: 03 APR 86 16:13:06
From: {ATE.R/CHESTNUT}ONTYME@OFFICE-1
To: tcp-ip@sri-nic.arpa
Subject: Removal from distribution listPlease remove me (RC.TYM@OFFICE-1) from the TCP-IP distribution list. The material has a slant somewhat different from what I had expected. Thank you.
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Apr 86 17:54:34 EST From: garry@batcomputer.tn.cornell.edu (Garry Wiegand) To: arpa.tcp-ip Subject: tcp for an AT&T 3b20 (got one?)
We've great big AT&T 3b20 (n o t the same as a 3b2!) standing around here lookin' dumb. Reason she's dumb (and deaf) is she only speaks "3b" protocol (whatever that may be) on the ethernet. Anybody have/heard of tcp implemented on this beast? garry wiegand garry%cadif-oak@cu-arpa.cs.cornell.edu
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Apr 86 21:17:27 EST From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU> To: dcp@SCRC-STONY-BROOK.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: FTP specs and conventions
One thing I wondered about is why the Symbolics FTP server responds to the LIST and NLST commands with exactly the same data? Was there a reason for leaving out the usual data like creation dates and sizes and such?
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri 4 Apr 86 01:42:47-MST From: Mark Crispin <MRC@SIMTEL20.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: nested replies, Milnet/ARPANET performance
Folks -
I'm sort of annoyed by the style of replies which include the
message being replied to in the reply. It gets rather tedious quite
quickly. Can we all make an effort not to do this? It's much better
to write a reply that makes the context of the message obvious than
to write one that has 5 or 6 new text lines in a 100+ line message...
I've complained about the Milnet/ARPANET performance for over a
year now. In the SF Bay Area the local ARPANET TAC is 300 baud only,
so most of us haven't even bothered getting an ARPANET TAC ID. This
is alright since there are lots of ARPANET hosts (Stanford, SRI)
around here for ARPANET access. But the SRI Milnet TAC is the only one
with dialups, and it gets heavy usage. If the TAC is busy or in
catatonic mode (a distressingly common occurance) I find myself cut off
from Milnet. It has been impossible to do serious heavy-duty editing,
real-time debugging, or any of the other software development tasks I
do here if I have to go through the Milnet/ARPANET gateways, and it's
been that way for over a year.
I'll grant that Telnet between ARPANET and Milnet is an abuse of
the gateways, but given the totally inadequate Milnet access around
here the choices narrow down to that or being cut off. Actually there
isn't a choice now; if the Milnet TAC is down we are effectively cut
off from Milnet.
I question the wisdom of maintaining the Milnet and ARPANET as
discreet networks. From what I can tell the perceived need for the
split has evaporated. There must be a lot of unnecessary trunk
duplication, not to mention all that gateway traffic which would go
away if we rejoined Milnet and ARPANET into a single net. How about
it, DCA?
-- Mark -- trying to do production work on two production nets, neither
of which are producing very good results...
-------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri 4 Apr 86 00:14:07-EST From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: Re: Core gateway slot problem
Has the problem of running out of Core gateway slots for connected networks suddenly gotten worse? Our network (128.45.0) seems to be going in and out (mostly out today) although our EGP process has been running continuously for the last three days. In the past my experience has been that once we got a slot we kept it until our gateway crashed. We've been having lots of trouble from our network lately also (128.59). Tons of mail is piling up here. /Ken -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 4 Apr 86 8:18:46 EST From: Ron Natalie <ron@BRL.ARPA> To: Richard Johnsson <johnsson@decwrl.dec.com> Cc: tcp-ip@sri-nic.arpa Subject: Re: Core gateway slot problem
Actually, I've noted a strange phenomena which I don't think is slot related. Periodically the a Reachability message is sent with a fewer number of nets but all pointed to a single (but different than usual) gateway. Any one else see this. (By the way, I haven't seen the GGP counting to infinity artifact showing up in EGP messages recently, so I guess that's been fixed).
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 86 11:50 PST From: Jeff Makey <Makey@LOGICON.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: Makey@LOGICON.ARPA Subject: Re: Core gateway slot problem
On April 3, at 16:31:56, 18:01:31, and 20:01:24 PST our SMTP server
received SYNs from CU20B.COLUMBIA.EDU (128.59.32.128) but was unable to
respond, being informed by SRI-MILNET-GW.ARPA (via ICMP) that the
destination net was unreachable. (LOGICON.ARPA is on the MILNET, so we
must go through the ARPANET to get to CU-NET.)
Why is it that CU20B can send packets to LOGICON, but sometimes we
can't send to them?
We finally did complete a connection at 22:39:07 PST. Also, we have
had this type of problem much more frequently with RED.RUTGERS.EDU
(128.6.4.2), whose internet gateway is also on the ARPANET.
:: Jeff Makey
Makey@LOGICON.ARPA
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Fri, 4 Apr 86 10:19 EST From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA> To: George J. Carrette <GJC@MC.LCS.MIT.EDU>, dcp@SCRC-STONY-BROOK.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: FTP specs and conventions
Date: Thu, 3 Apr 86 21:17:27 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
One thing I wondered about is why the Symbolics FTP server
responds to the LIST and NLST commands with exactly the same data?
Was there a reason for leaving out the usual data like creation
dates and sizes and such?
Because the code for :LIST says
;; Some day do better than this.
and then calls the NLST code. Thanks for pointing this out.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 04 Apr 86 11:02:06 EST (Fri) From: Mike Brescia <brescia@BBNCCV.ARPA> To: Ron Natalie <ron@brl.ARPA> Cc: Richard Johnsson <johnsson@decwrl.dec.COM>, tcp-ip@sri-nic.ARPA Subject: reissue: Core gateway routing bug found
I do not recall seeing a copy of this message returned from NIC. Thursday, April 3 is the first full day which should show sanity in the routing. Mike --- copy etc. --- To: tcp-ip@BBNCCV.ARPA Subject: Core gateway routing bug Date: 02 Apr 86 14:21:09 EST (Wed) From: tmallory@BBNCCV.ARPA A bug in the routing code of the LSI-11 gateway software has been isolated which is responsible for most of the problems experienced by users of the core gateways for either routing or packet transmission. The bug caused oscillating routing and added greatly to the amount of overhead traffic associated with routing, contributing to congestion on the Arpanet and Milnet. We have started patching all of the core gateways. This will take some time, though we hope to have the initial pass complete sometime tomorrow. It will take several days to update all of the load devices, so minor problems may reappear as gateways with old binaries are reloaded during the normal course of operations(power failures, etc.). Thank you all for your patience, Tracy Mallory BBNCC
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Fri, 4 Apr 86 11:50:16 EST From: Ra <root%bostonu.csnet@CSNET-RELAY.ARPA> To: security@red.rutgers.edu, tcp-ip@sri-nic.ARPA Subject: Thought on data encryption on networks
Most of us run networks that do not have any encryption facilities (perhaps in theory, but not something a sys mgr can just turn on.) The problem is that the minute someone says 'hey, we need some encryption on this net' out come the macho data encryption types to explain to you that the only encryptions worth doing are too expensive (or complicated) to run, and then slink away again leaving you defenseless. Worse, you usually end up sitting thru a long scolding about how even if you implemented the best it is probably about to be broken or illegal or something. Oh, where is Arthur to slice this gordian knot? Meanwhile, Joe Cracker plugs his PC into your net, goes into promiscuous mode and has the most fun he can with his pants on. How outlandish would it be to come up with (I am probably not qualified to do this, although those that are probably won't) some sort of reasonably hard to crack stream oriented protocol? There has to be something in between clear text and you-need- a-cray-ethernet-board-but-it-cant-be-cracked. Suggestions? If your inclination is to say 'yer iggorant, this is solved' then how come none of the major O/S's have put it into their device drivers or wherever? -Barry Shein, Boston University
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 1986 13:29:09 EST From: MILLS@USC-ISID.ARPA To: sy.Ken@CU20B.COLUMBIA.EDU, tcp-ip@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: Core gateway slot problem
In response to the message sent Fri 4 Apr 86 00:14:07-EST from sy.Ken@CU20B.COLUMBIA.EDU Ken, I suspect BBN warriors may be too bloodied and weary to have announced a damage report, so please treat the following as an unofficial summary. When the core tables were expanded over 128 nets at least two bugs developed which reesulted in broken, oscillating routes within the core system. The problems then led to massive surges in gateway control traffic, as well as massive surges in redirects, not to mention aimlessly wandering datagrams carrying possibly useful user traffic. The situation became acute about a week ago, since when BBN has been feverishly updating all the core gateways, some of which are fiendishly hard to update (bubble memories, etc.). In the last couple of days things have improved, which is a good sign. The evidence is not hard to detect upon inspection of the EGP hop-count fields received by your EGP peer. You may notice the gateways wandering about the ARPANET or MILNET, as well as the high incidence of unusually large hop counts, not to mention the incidence of nets bobbing up and down. I have also noticed locally a marked increase in the incidence of ARPANET host-down messages, which may be realted to gateway reloading and the suspected traffic surges. My personal, unsubstantiated suspiciion suspicion is that instabilities in the core routing system due inconsistent tables (becasue of overflow) may have contributed significantly to the recent deterioration in performance. Dave -------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Fri 4 Apr 86 17:03:05-PST From: "RAJENDRA K JAIN" <jain@hudson.dec.com> To: "tcp-ip" <tcp-ip@sri-nic.ARPA> Subject: Timeout algorithms for packet retransmissions
Some time ago, there was a discussion of retransmission timeout algorithms on this forum. To those still interested in the topic I would like to point out that a survey of various algorithms and their problems was published recently: Jain Raj, "Divergence of Timeout Algorithms for Packet Retransmissions", IEEE Phoenix Conference on Computer Communications, Phoenix, AZ, March 27-28, 1986, pp. 174-179. The paper has 17 references to other papers on the subject. If you can't find the proceedings in your local library, I would be happy to mail you a reprint. Please send your U. S. Mail address to Jain@Hudson.DEC.Com *** Please do not directly reply to this message. *** Regards. -Raj Jain ------
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 4 Apr 1986 14:29:47 EST From: MILLS@USC-ISID.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Martians go home
Folks, I just caught a beta-4.3bsd coughing up ICMP Source Quench and claiming its address to be 127.0.0.1, but truly was on a net-128.5 subnet. This is yet again evidence supporting the well-travelled axiom that says to resist the urge to encroach on the net-address space as a substitute for intra-host routing mechaniss. I would like to suggest that a new net be conceived called DEAD-LETTER with net number 127.0. Volunteers are invited to submit gateways to that net. Dave -------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Fri, 4 Apr 86 15:26:57 EST From: Mike Muuss <mike@BRL.ARPA> To: Ra <root%bostonu.csnet@csnet-relay.arpa> Cc: security@red.rutgers.edu, tcp-ip@sri-nic.arpa Subject: Re: Thought on data encryption on networks
There are two levels of protection that you require: *) Link-level protection, to keep people from disrupting your local cable(s). *) End-to-End protection, to keep your conversation private even if some (or all) of the cables that carry the conversation are not protected. Link-level protection is a local issue -- if you can find a vendor who will sell you, say, Ethernet cards with 10 Mbps DES encryption built in, you could replace all the boards on your cable(s), and be protected. End-to-end protection will only work if both ends are expecting it. As there is presently no presentation level (ISO level 6) encryption defined for the TCP protocol family, you won't be able to use this very well. (Let me encourage you to consider how to optionally negotiate in end-to-end encryption on top of a TCP connection, and write up an RFC!) Also, note that this will probably have to be a software implementation, so that it can be specified for, and added to, all the existing TCP implementations. This may have a performance impact. There is also the issue of key management, which in a relatively static system like the DARPA Internet (as opposed to a tactical network) is fairly easy to implement (tedious, but possible). Note that for the military community, the BLACKER system addresses the end-to-end needs, as well as the key management issues. Link-level encryption is still the responsiblity of the individual link managers. -Mike
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 1986 16:29-CST From: SNELSON@STL-HOST1.ARPA To: TCP-IP@SRI-NIC.ARPA Cc: SNELSON@STL-HOST1.ARPA Subject: THOUGHT ON DATA ENCRYPTION ON NETWORKS
MIKE MUUSS THOUGHTS IN REPLY TO MKE BRESCIA ARE AS SUCCINCT AS THEY CAN GET. I AGREE. I HAVE BEEN USING THE HERMES MAIL ENCRYTION FEATURE FOR A LONG TIME AND IT ASSURES THE PRIVACY I DESIRE. I THINK THE DECISION MAKERS ARE GOING TO HAVE TO DEFINE THE DIFFERENCE BETWEEN INDIVIDUAL PRIVACY AND SECURITY OF INFORMATION. IT IS THE SAME OLD STORY. MANAGEMENT HAS TO DECIDE WHAT NEEDS PROTECTION, WHAT IS NICE TO HAVE AND WHAT DOESNT MEAN ZILCH. STEVE
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Sun, 6 Apr 86 09:23:19 EST From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU> To: root%bostonu.csnet@CSNET-RELAY.ARPA Cc: tcp-ip@SRI-NIC.ARPA, security@RED.RUTGERS.EDU Subject: DADA & Encryption
There is a very simple and cheap encryption method that is also the only one known to be impossible to break. That is a one-time-key method. I have been using this by putting it into the applications such as FTP right at the places that streams are opened. The practical restriction of a one-time-key method is that you must generate a tape (or other secure medium) of enough random bytes and then send it by a trusted person to the machine you want to send messages to. Then, each time you send a byte to the other host XOR it with one from your key-tape. If you never repeat your key then nobody will be able to break the code except by stealing the key. If what you want to encrypt is mail traffic then a 1 gigabyte video disk would probably do for a quite a few months before you have to make and send another one. On the other hand, with a key as long as a gigabyte you could risk repeating it because a spy would have to be listening for quite a while to catch a repeat key, so it would take care of a random with an IBM-PC Unless of course he also had a gigabyte of video disk to write to in real time over the course of a few months.
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Sun, 6 Apr 86 09:35:41 EST From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU> To: DCP@SCRC-QUABBIN.ARPA Cc: tcp-ip@SRI-NIC.ARPA, dcp@SCRC-STONY-BROOK.ARPA Subject: FTP specs and conventions, LIST command
Of course it is extremely unfortunate that there is no spec for the format of the data in the LIST command. If only there was an RFC for a more reasonable file access protocol...
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 6 Apr 86 18:54:48 EST From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU> To: Makey@LOGICON.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Core gateway slot problem
Asymmetry in routing is quite easy to occur. In order to send a packet from us to you, we have to know about our own local gateway, and our local gateway has to know about some Arpanet/Milnet gateway. We always know about our local gateway (it is hardwired in our routing table), and I am fairly sure our gateway always knows about one of the core gateways. This means that we can always get packets to any host that is directly connected to the Arpanet or Milnet. In order to respond, your host must know about an Arpanet/Milnet gateway and that gateway must know about our local gateway. Again, you probably always know about some Arpanet/Milnet gateway. Recently, due to various bugs that have been discussed here enough, the Arpanet/Milnet gateways have had a tendency to lose track of external gateways such as ours. The result is that you can't get a packet back to us. When the core gateways lose track of us, we can often establish connections to machines that are directly on the Arpanet by sending them redirects pointing to our gateway. We haven't been very successful in doing this to sites behind a gateway. (The fact that we can do it at all is, of course, a security problem. As far as I can tell, anybody on the network can change around any 4.2 system's routing table in any way that he wants.) -------
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Apr 86 07:56:31 est From: Gavin Hemphill <hemphill@nrl-aic> To: tcp-ip@sri-nic Cc: drenet@drea-xx Subject: Performance Improvement?
Well whatever was done re fixing bugs in the core gateways HAS made a difference. The performace between MILNET and CDNNET via ARPANET has NEVER been better than it has since the middle of last week. I don't have any quantitative measurements (though someone with more expertise might want to gather the stats), but the percieved response to Telnet and FTP has been super G++
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Mon, 07 Apr 86 13:15:47 -0500 From: /Steve Dyer <dyer@harvard.HARVARD.EDU> To: tcp-ip@sri-nic.ARPA Subject: Excelan TCP/IP boards for PC/ATs
Does anyone have any direct experience with the Excelan 205 ethernet
controllers and EXOS 8111 software for the IBM PC and AT? I'm interested
in exploring ways to interconnect a bunch of PCs, some running XENIX,
others running DOS. After exploring the market, it looks like Excelan
may be the only solution available right now, given that XENIX access is
necessary.
--
Steve Dyer
dyer@harvard.HARVARD.EDU
{bbncca,bbnccv,harvard,ima,ihnp4}!spdcc!dyer
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Apr 86 11:44:20 est From: Gavin Hemphill <hemphill@nrl-aic> To: tcp-ip@sri-nic Cc: drenet@drea-xx Subject: ooops, I meant to say DRENET
Date: Mon, 7 Apr 86 07:56:31 est From: Gavin Hemphill <hemphill@nrl-aic> Well whatever was done re fixing bugs in the core gateways HAS made a difference. The performace between MILNET and DRENET (not CDNNET) via ARPANET has NEVER been better than it has since the middle of last week. I don't have any quantitative measurements (though someone with more expertise might want to gather the stats), but the percieved response to Telnet and FTP has been super G++
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Mon, 07 Apr 86 19:48:31 -0500 From: Gurudatta Parulkar <parulkar@dewey.udel.EDU> To: tcp-ip@dewey.udel.EDU Subject: Flooding
It seems that some kind of flooding was explored as routing strategy for ARPANET long back. But it never became popular. I would like to get some pointers to papers, reports, RFCs, etc. which talk about this flooding and also talk about why it was given up. Could somebody help me with these pointers ? We at University of Delaware are exploring the possibility of using flooding in a LAN. Are there any other groups looking into such a possibility ? Please send me a note. Thank you very much. -guru :______________________________________________________________________________ :Gurudatta M. Parulkar :University of Delaware :Department of Computer and Information Sciences :Newark, DE 19716 : :ARPA: parulkar@dewey.udel.EDU :CSNET: parulkar%dewey.udel.EDU@csnet-relay :UUCP: ...!harvard!parulkar@dewey.udel.EDU :______________________________________________________________________________
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Apr 86 19:33:49 EST From: Mike Muuss <mike@BRL.ARPA> To: Gavin Hemphill <hemphill@nrl-aic.arpa> Cc: tcp-ip@sri-nic.arpa, drenet@drea-xx.arpa Subject: Re: Performance Improvement?
I concur. A quick test to Berkeley showed roughly 2 second RTT, which is much better than before. Not great, but usable. Thanks! From BRL-VGR: ----monet.berkeley.edu PING Statistics---- 59 packets transmitted, 57 packets received, 3% packet loss round-trip (ms) min/avg/max = 1090/1953/5500 -Mike
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Apr 86 20:03:10 EST From: Mike Muuss <mike@BRL.ARPA> To: PADLIPSKY@usc-isi.arpa Cc: TCP-IP@sri-nic.arpa Subject: Encrypt at which level?
Mike Padlipsky asked why I thought Level 6 was the right place to implement encryption, and even though my answer is sketchy, I figured I'd share it with everybody. It seems to me that code translation, e2e encryption, and some sort of standard data compression ought to be available as "protocol family" services to *any* application, just for the asking. At the right point in the dialog (perhaps before the first data byte, perhaps after some initial exchange), the user program should make some kind of call to the next lower level interface and say "please begin encrypting with a key of XXX". The exact implementation point of e2e encryption isn't REALLY important though, as long as a good place for it in the protocol suite exists, and most everybody can be made to agree to do it there. It could be provided by a library function, or as direct code within each application, or as an operating system capability, I dont really care, but I feel that some basic level of encryption should be available as a primitive capability. It would be nice, for example, to consider an extention to the SMTP protocol to go something like: 220 brl-sem Server SMTP (Complaints/bugs to: mmdf@brl.arpa) HELO brl-sem 250 brl-sem CRYPT 250 encryption with our common key being enabled. MAIL FROM:<mike@brl-sem> 250 OK and thus have both the address and data portion encrypted (as an option). TELNET IAC-DO-ENCRYPT etc etc might also be nice. Government sites handling what used to be called "For Official Use Only (FOUO)" data and researchers with unpublished data to exchange would be the most likely candidates to desire this type of capability. The key management issues would be a drag. Host-pair, Group-pair, User-pair basis, or what? How to update? What to do when the keys don't match? Handling the user interface issues would also take thought and work, but encryption is something that WOULD be useful to have. How this fits together with Multi-Level Secure hosts interfacing to BLACKER isn't clear either. The simple answer is: "not at all -- BLACKER is different", yet having BLACKERs protecting gateways to LANs *still* does not handle the complete end-to-end requirement. BLACKERs protecting hosts would. I need to think about this more. -Mike
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 1986 11:03-PST From: postel@usc-isib.arpa To: tcp-ip@SRI-NIC.ARPA Subject: Flooding
The current IMP level routing procedure is basically a flooding type algorithm. Here are two references for further information. --jon. ----- McQuillan, J. M., I. Richer, E. Rosen "An Overview of the New Routing Algorithm for the Arpanet," Proceedings of IEEE, Spring 1979. "The New Routing Algorithm for the ARPANET," IEEE Transactions on Communications, May 1980, pp. 711-719.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 Apr 86 12:23:25 pst From: lekash@AMES-NAS.ARPA (John Lekashman) To: tcp-ip@sri-nic.ARPA Subject: clogged queues
We have a machine that is reading IP packets and occasionally getting clogged with data, some for undefined addresses, some for processes being slow. It is on a LAN, (hyperchannel to be precise.) I'm looking for advice on which end of the queue to have the driver throw things away when its full. Both cost the same. thanks john
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 86 12:40:00 PST From: <gary@acc.arpa> To: "hunt" <hunt@bbnccj> Cc: arpanetmgr@ddn1,tcp-ip@sri-nic Subject: alias...
Doug, Who is the "Arpanet Program Manager" at the DDN PMO?? What group does he/she fall into? Thanks, Gary ------
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 Apr 86 9:41:31 EST From: Jim Berets <jberets@BBN-VAX.ARPA> To: Mike Muuss <mike@BRL.ARPA> Cc: tcp-ip@sri-nic.ARPA Subject: Re: Encrypt at which level?
Mike, A little bit of looking through my file cabinet revealed a "draft proposed ANSI standard for Presentation Layer Encryption" dated April, 1984. "The primary purpose ... is to define the functional and procedural characteristics of cryptographic operations ... on behalf of a requesting application layer entity (End User)." At the time, this standard was being developed under the auspices of ANSI X3T1. Interested parties could probably obtain updated copies from ANSI. Jim <jberets@bbn-vax>
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 1986 1734-PST (Tuesday) From: Aki Shohara <shohara@sri-tsc.ARPA> To: se Cc: TCP-IP@SRI-NIC.ARPA, Makey@LOGICON.ARPA Subject: Re: Core gateway slot problem
This message erroneously routed to me. aki shohara.
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 Apr 86 9:01:19 BST From: Steve Kille <steve@ucl-cs.arpa> To: mike@brl.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Encrypt at which level?
I agree that for many cases, encypting at level 6 seems correct. I note that the ISO presentation has hooks for this. However, this is not sufficient for store and forward services (or any spooled service) such as mail. Here, to obtain end to end encryption, it will need to be at the application level. Marshall Rose wrote a very good paper on the mail issues for the Washington 85 IFIP 6.5 Symposium (published North Holland). It also describes an implementation. Steve
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 Apr 86 15:14:44 EST From: Doug Hunt <hunt@bbnccj.ARPA> To: tcp-ip@sri-nic.arpa Cc: arpanetmgr@ddn1.arpa, hunt@bbnccj.arpa Subject: note on recent arpanet performance problem
Status of Remedial Action for Arpanet Performance Problems
This note describes an Arpanet performance problem, together with the
steps being taken to correct it. The discussion covers (1) the
symptoms, (2) an explanation of the problem, (3) the recommended
solution, and (4) a timetable for implementing the solution. This note
concludes with a recommended procedure for reporting Arpanet performance
problems to the Arpanet Manager at the DDN Program Management Office.
The Symptoms
Basically, the Arpanet appears sluggish -- interactive as well as bulk
transfer traffic can be subjected to very large delays. This can
manifest itself as an overflowing typeahead (input) buffer to a TAC, or
a file transfer that takes much longer than should be required for the
file size and data path bandwidths involved.
The Problem
The BBNCC Network Analysis Group considered a number of hypotheses that
could explain the sluggish network behavior. They have found that much
of the performance degradation in the Arpanet can be traced to host
blocking owing to a lack of per-connection resources in PSNs. This
blocking would exhibit the symptoms described above.
A host must have a PSN allocate to it certain resources in order to
establish and use a host-host network connection. To establish the
connection, both the source and destination hosts must be allocated
"connection blocks" by their respective source and destination PSNs.
Having done so, to send a message a host must be allocated a "message
number". The connection blocks and message numbers are resources
internal to the PSN; until a PSN allocates these resources to a host,
the host is blocked.
Analysis of the Arpanet in recent months shows that, for many PSNs,
there is excessive blocking of attached hosts because of a shortage of
connection blocks. Twelve PSNs in particular exhibit this problem
consistently. These PSNs are: SRI2, RCC5, STAN11, DCEC20, ISI22, ISI27,
PURDU37, SRI51, LBL68, SAC80, BBN82, and WISC94. Alleviating the
connection block shortage problem for these and other Arpanet PSNs
should provide a significant improvement in network performance as seen
by hosts.
The Solution
The PSN release used on the Arpanet, "Release 3/4", supports only 73
connection blocks in each direction -- enough to support 73 full-duplex
streams. Measurements have shown that, for many PSNs including those
listed above, there is excessive contention for these 73 connection
blocks. Analysis of the traffic patterns of the attached hosts
indicates that increasing the number of connection blocks to 255 -- the
number supported in PSN Release 5 -- should greatly reduce the
likelihood of hosts blocking owing to a connection block shortage.
The Timetable
On March 12, the DDN Program Management Office (PMO) issued a "Network
Change Directive", authorizing the installation of PSN release 5 to most
Arpanet sites prior to May 2, 1986. A few sites will not receive the
new release until later, since those sites have not yet had the hardware
upgrade necessary to support PSN release 5. Those sites with the most
serious performance problems will be the first sites to receive the new
release. PSN release 5 has already been subjected to extensive
operational use, as the DDN PMO has previously authorized the
installation of PSN release 5 on other networks, such as the MILNET.
Recommended Procedure for Reporting Arpanet Performance Problems
In order to facilitate resolution of performance problems on the Arpanet
it is important that the Arpanet Manager at the DDN PMO be informed of
problems noticed by Arpanet users. Currently, the Arpanet Manager at
the DDN PMO is Captain Callaway. Arpanet users are encouraged to
include this office, with mailbox "arpanetmgr 'at' ddn1", on network
mail regarding Arpanet problems. The description of the problem should
be as detailed as possible. Include information such as:
1. description of problem
2. time of day problem occurs
3. duration of problem
4. host you are using
5. gateway you are using (if applicable)
6. host you are attempting to reach
7. general description of computing you are engaged in -- e.g., "I am
transferring files from my host to host XYZ. Approximate size of
file is 64k bytes".
8. provide any other information you think would be helpful in
resolving the problem.
Since the DDN PMO establishes the policies for operating and managing
the Arpanet, it is important that the PMO Arpanet Manager be aware of
problems experienced by Arpanet users.
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 8 Apr 1986 16:07:17 EST From: PADLIPSKY@USC-ISI.ARPA To: mike@BRL.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Encrypt at which level?
In response to your message sent Mon, 7 Apr 86 20:03:10 EST Mike-- Oh, dear, now you've gone and made me violate my vow not to work up a sweat over ISOmetrics in public anymore.... After several drafts that got too esoteric, I'll try to confine myself to a couple of brief (possibly cryptic, but no pun is intended) observations: In the first place, by Sutton's Law it does make sense to "floogle" at L6; it's where the data are. However, doing so would leave the lower L's headers unfloogled, which I don't believe is consistent with what its proponents seemed to think "end-to-end encryption" implied back in the bygone days when I occasionally talked to them (informally, of course). Let's pretend you meant "data encryption." (Or not, since it's more or less a purist's point, along the lines of trying to prevent anybody who has a different set of associations/connotations with/for E-E E from being misled.) In the second place, putting floogling at L6 gives rise to all sorts of questions I don't know the answers to about the nature of the L7-L6 interface (which led me down a devious route I don't want to go into here to a perception of still another architectural inelegancy in the Seven Story Highrise). For a while, I thought L6 floogling would require L6 to take inappropriate cognizance of L7's distinction between control and data. Then I thought that floogling didn't but being able to virtualize and devirtualize the data did. Now from Steve's response I begin to wonder if I was right in the first place (and I still think I'm part right in the second place). Perhaps Steve will respond further if I just assert that it's not obvious to me that you HAVE TO floogle at L7, unless it has something to do with needing the control information to be in the clear while the data are still encrypted (or befloogled, as the case may be). Anyway, as of now I wish I hadn't asked...and if I let myself go on any longer I imagine everybody else will wish so too, so I'll steer clear of such fun topics as whether floogled sessions, transport connections, and network-layer connectionless whatevers (associations, maybe) are or aren't meaningful, muchless the possible significance of floogling at the top, middle, or bottom of a layer. (But it would be delightful to take them up one at a time if anybody else feels like it.) cheers, map P.S. In case anybody's curious, Sutton was "Willie-the-Actor," and when asked why he robbed all those banks he's alleged to have replied "Because that's where they keep the money." -------
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 08 Apr 86 21:58:18 EST (Tue) From: "Thomas Narten" <narten@Purdue.EDU> To: tcp-ip@sri-nic.arpa Subject: Ethernet monitor wanted
We were recently struck by an unusual and deadly problem that killed our Ethernet and many of the machines on it. The problem was apparently caused by a piece of hardware that didn't take a power surge well. The problem consisted of two things: The net became jammed with bogus traffic (not legal packets), and lots of corrupted packets that had correct Ethernet checksums in them. The jamming was intermittent, and temporary, but the effects of the corrupted packets were felt for quite a while. IP packets were OK because they were checksummed at higher layers. During one 3 hour period, one of our machines recorded over 200,000 IP checksum errors. Unfortunately, ARP relies on the Ethernet checksum and hence the ARP tables became severely corrupted. You can imagine the confusion this caused. (i.e. connections break, the ability to reach a host comes and goes, ...) Conclusion (as noted in this mail list before): its tough debugging a network without tools. We were fortunate enough to have MIT's PC monitoring program that plugs into the Ethernet and prints out everything it sees. It was extremely useful to us. In using it, however, I thought a more general monitoring program would be extremely useful (even during times the network is functioning normally). I am wondering what (if any) other sorts of "promiscuous reader" programs have been written and if they are available for use. Things that would be useful include: Having massive statistics gathered over a period of time. It would be nice if the program could be run for an hour/day/week to accumulate information about numbers/types/sizes of packets. This information could (perhaps later) be broken down in such a way that one could see all the stats for a given source address, or a given destination (i.e. broadcast would be interesting), packet type (i.e. protocol), etc. It would also be useful to have an interactive, screen oriented program that lets you select what you see. This would be most useful when tracking down problems. Do any such programs exist? What are there capabities? What other sorts of things would be useful to include? Thomas Narten ----------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Apr 86 00:44:13 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) To: narten@Purdue.EDU Cc: tcp-ip@sri-nic.arpa Subject: Ethernet monitor wanted
I'm extending MIT's "netwatch" monitor for my company. Right now I'm planning on adding the features you've mentioned (long term statistics gathering), plus some more real time statistics gathering, and error indications. We'll be announcing the new product at the end of the month. I'm also thinking about adding a really neat mode for TCP where it will pick up all the TCP packets that go by for a connection and analyze them, reporting things like out of sequence packets, retransmitted packets, and detecting problems like silly window syndrome. I don't think it should be too incredibly difficult to do. Maybe it'll show us how bad all of our TCP's *really* are... I'd also really like to hear from other people on what features they think would be useful. What are the most common protocol failures you find? What would you most like to be able to do with an independent monitor while debugging a new protocol implementation? - john romkey ftp software
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Apr 86 02:00:04 EST From: Ra <root%bostonu.csnet@CSNET-RELAY.ARPA> To: narten@purdue.edu, tcp-ip@sri-nic.ARPA Subject: Re: Ethernet monitor wanted
There is a program, 'traffic' that runs on SUN3s (it comes with the SUN release tape) that does at least part of what you want. It uses the bitmap display to draw nice graphs of what's going on and from/to whom. There are various panels that can be selected for viewing. In addition they have a program 'etherfind' that takes a classic "ya hadda be there since V6 or you're lost" 'find' kinda pattern and dumps ethernet info like vmstat to any terminal, it's also very helpful (eg. I could hear a diskless node crying for a rarp and verify that no one was answering, and, past that, watch a tftpboot fail, all ultimately caused by set up files being wrong, but it was nice to see something.) -Barry Shein, Boston University (that reference is to V6 UNIX of course...sorry)
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Apr 86 03:22:26 est From: karn@mouton.ARPA (Phil R. Karn at mouton.ARPA) To: tcp-ip@sri-nic.arpa Subject: Re: Encrypt at which level?
I thought this issue was resolved long ago -- if you're really paranoid you need to do it twice, on an end-to-end basis (transport or above) to protect the information in the message AND on a hop-by-hop basis (link level) to guard against traffic analysis. Phil
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 9 Apr 1986 07:54:25 PST From: Dan Lynch <LYNCH@USC-ISIB.ARPA> To: "Thomas Narten" <narten@PURDUE.EDU> Cc: tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA Subject: Re: Ethernet monitor wanted
There is a commercial product out now called the LANalyzer, from Excelan, that does much of what you want and has even more features. In order to be sure of capturing all packets it comes packaged as a board that plugs into an IBM Xt (or above or a compatible, of course) plus the software to drive the board and display the packet info in many different formats. IN addition to sniffing for anything you can imagine it can also generate packets of any variety and thus allow one to see how a target system performs under known "assault". The baord plus software goes for under $10K. They can be reached at 408-434-2300 for more info. Dan -------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Apr 86 08:16 EST From: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA To: tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Re: LAN flooding.
In response to:
:Gurudatta M. Parulkar
:University of Delaware
:Department of Computer and Information Sciences
>We at University of Delaware are exploring the
>possibility of using flooding in a LAN. Are there
>any other groups looking into such a possibility ?
>Please send me a note.
Maybe I missed something here. The LANs I know of all have a broadcast
address available to them. Why would you want to flood a LAN when one
packet will do?
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Apr 86 08:42 EST From: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA To: tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: TCP/IP and DECNET
We at Northeastern University have a growing contingent of both
TCP/IP nodes (UNIX) and DECNET nodes (VMS). I had a brilliant idea the
other day. Why not get ULTRIX to translate between TCP/IP and DECNET.
This would certainly seem a logical place to do it because ULTRIX
understands about both. You would also only need one of these nodes on a
network to do the gateway job of translation. A WONDERFUL idea right?
Guess what ULTRIX can't do folks. Apparently with a funny
sendmail.cf you CAN route mail from the TCP/IP world to DECNET but not
back and FTP is just NOT possible. Remote login isn't doable either.
Why is the world so perverse? Why do brilliant ideas come
stillborn? I didn't think I wanted much. When I was asking about
various vendor's TCP/IP for VMS awhile back, nobody really liked any
vendor software. I heard all kinds of horror stories right and left.
I thought here would be a chance to get both worlds in one box but
NOOOOO. (cry cry sob sob *sigh*).
Does anybody out there know of someone trying to solve the problem
of getting ULTRIX to do the right thing between TCP/IP and DECNET? Is
DEC maybe? Please (whimper whimper)?
Chris Johnson
Northeastern University
johnson@northeastern.csnet
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Apr 86 11:44:50 pst From: imagen!geof@decwrl.DEC.COM (Geof Cooper) To: narten@Purdue.EDU Cc: tcp-ip@sri-nic.ARPA Subject: Re: Ethernet monitor wanted
> I am wondering what (if any) other sorts of "promiscuous reader" > programs have been written and if they are available for use. I believe that Excelan makes such a device. - Geof
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Wed 9 Apr 86 13:22:37-PST From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA> To: LYNCH@USC-ISIB.ARPA Cc: narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA, OLE@SRI-NIC.ARPA Subject: Re: Ethernet monitor wanted
CMC (Communication Machinery Corporation) of Santa Barbara has an Ethernet monitor, the DRN-1700 (aka "Spidermonitor" from Scotland). Contact Russ Sharer (805) 963-9471 for details. Ole -------
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 1986 00:42-EST From: CERF@usc-isi.ARPA To: parulkar@dewey.udel.EDU Cc: tcp-ip@dewey.udel.EDU Subject: Re: Flooding
Flooding is used in the current Shortest Path First Routing algorithm. Check with Steve Cohn at BBN for references. Vint
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 1986 1202-PST (Thursday) From: lewis <lewis@sri-tsc.ARPA> To: tcp-ip@sri-nic Cc: Subject: Re: Ethernet monitor wanted
For those with SUN3 workstations, there is a graphical Ethernet watch program. You start up the rpc.etherd in the background, and the user program is called "traffic" in usr/bin I think. It of course uses permiscuous mode. The user is able to split his window into several displays for parsing packets into time varying histograms by protocol, host, or destination, the 8 busiest sources are displayed. You can also view load, ei 100% is 10 Megabits/sec. It does not keep long term statistics. There is another SUN3 etherwatch program with a non-graphical interface, and if it collects statistics, I will post a description after I look at it. -Mark Lewis
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Apr 86 9:14:38 EST From: Ken Lebowitz <kjl@bbn-clxx.arpa> To: tcp-ip@sri-nic Subject: VMS TCP/IP on a serial line?
Can anyone tell me if Wollongong's networking code for VMS is capable of
performing TCP/IP through a serial line device? Has anyone out there
actually done this (I seem to remember somebody having done this on a UNIX
host)?
Thanks,
Ken Lebowitz
BBN Laboratories
ARPA: kjl@bbn-clxx.arpa or kjl@clxx.bbn.com
UUCP: ...!{decvax,ihnp4,harvard}!bbncca!kjl
CSNET: kjl%bbn-clxx.arpa@csnet-relay
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 86 16:06:22 EST (Thu) From: Frederick E Serr <fserr@BBNCC5.ARPA> To: Bill Chiarchiaro <wjc@ll-vlsi.ARPA> Cc: tcp-ip@sri-nic.ARPA Subject: Re: ARPAnet Usage
During the second week of December, 1985, the busiest node on the ARPANET was RCC5, here at BBN. It handled the following numbers of packets per second: From Into Out Hosts Hosts Trunks Average 16 21 77 Peak Hour 18 28 77 The first row is the average over five days (Mon-Fri), 24-hours per day. The second row is for a busy hour (identified as a peak for the entire net, it may not be THE peak for this node). During this same hour packet rates of over 100/sec out internode trunks were observed on other nodes. This node has six busy hosts on it, including several gateways. I hope that this somewhat delayed response still provides some useful info.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Apr 86 17:45:16 EST From: Louis A. Mamakos <louie@trantor.UMD.EDU> To: tcp-ip@sri-nic.arpa Subject: Wollongong problem
Ah yes, the TELNET end-of-line discussion surfaces again. I inquired about this on the list a few years ago while I was writing the TELNET server for our Sperry 1100 host. The feeling at that time was that the correct action for an end-of-line was the CR LF sequence. This works out pretty well since the Sperry machine is a line at a time type machine. The TELNET session is symmetric; it sends lines terminated by CR LF to you, and you reply in turn. It seems that a problem like this should be fairly easy to accomodate in my TELNET server, but what do we have standards for? We have this same problem with our Wollongong host, and have beat on the vendor to fix this. The user TELNET with Berkeley 4.2 was damaged in a similar fashion and it was a simple 3 line fix to the program. Its been more than a year, and the Wollongong people have yet to address THIS simple problem; let along hard ones like subnetting. This seems to have degenerated into a flame; sorry about that. I just wanted to make the point that the fuzzballs are not the only hosts that are upset by this particular bug. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Apr 86 17:57:12 EST From: jas@proteon.arpa To: tcp-ip@sri-nic.arpa Subject: naked CR's
The server telnet in Ultrix-32m V1.1 has the same bug. My local user telnets can cope, but only after they recieve one more character. Unfortunately, smart editors on Unix send naked CR to implement "go-to-beginning-of-line", so you lose big with this sever telnet. (I presume this is a standard raw 4.2BSD bug, and that DEC fixes it in V1.2.) -------
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 10-Apr-86 13:44:35-UT From: hwb@gw.umich.edu To: tcp-ip@sri-nic.arpa Cc: hwb@GW.UMICH.EDU Subject: Packet switch rates.
Hi: What packet transfer rates are people observing in IP switches these days. I would be interested in some figures of dedicated switches as well as through machines that also serve a host function. A good example would be a packet rate per second for a switch that connects two Ethernets, but other examples would be appreciated, too. As I think that this is of general interest I would suggest to post the examples to this list. -- Hans-Werner Braun -------
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 10 Apr 86 18:55 EST From: Rudy.Nedved@A.CS.CMU.EDU To: tcp-ip@sri-nic.arpa Subject: telnet
Wait until you try to use the binary option in connection with telnet. CMU has lots of special terminals that use the 8th bit....but there are two communities of busted telnet servers. 4.2BSD puts you in "raw" mode instead of just passing the 8th bit thru and some IBM sites that use EBCDIC (sic?) use the BINARY option to mean no translation [I don't remeber seeing an TELNET option to change from NVT ASCII to EBCDIC.]. Given that the majority of machines around here implement 4.2BSD telnet, we are going to "hack" our systems to send out IAC WILL BINARY to indicate that the system is NOT a busted 4.2BSD site. I hope 4.3 does not have this bug too and that they finally fix the EOL problems. I can understand how the old telnet servers and user programs got incorrectly implemented but any future servers should be fixed since the specifications for the options and telnet have been cleaned up alot. You just have to read them VERY carefully and completely. The only implementation of telnet that seems to be ALMOST correctly implemented is TOPS-20 telnet. (Maybe?) there is a race condition bug for the option negotiations (it loses information) and some questions about CR NUL handling which implies a bare CR versus CR LF. -Rudy
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Apr 86 18:59:14 EST From: Martin Schoffstall <schoff%rpics.csnet@CSNET-RELAY.ARPA> To: kjl%bbn-clxx.arpa@csnet-relay.arpa, tcp-ip%sri-nic.arpa@csnet-relay.arpa Cc: weltyc%rpicie.csnet@CSNET-RELAY.ARPA Subject: Re: VMS TCP/IP on a serial line?
well.. we have been trying to do this with help from the TWG development group. We just applied the latest vms patches to make it compatible with rick@seismo's SL software but it didn't work. We are going to modify the SL code shortly if we can't get VMS "fixed". marty
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 Apr 1986 00:06 MST From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: WANCHO@SIMTEL20.ARPA Subject: PCs and TACs
Perhaps because this host holds the largest collection of anonymously FTPable "public domain" software on the Internet, we are probably indirectly responsible for a high volume of not only those FTP transfers, but also high volumes of down and uploads between many hosts and users with PCs on TACs. Also, with widely available PCs, we have found many people downloading entire mail files and composing responses offline for later uploads and adding to the volume of such traffic. Most of these transfers are done using some variant of the Christensen Protocol, commonly misnamed "xmodem" protocol, or KERMIT. Although the KERMIT protocol allows for user-settable packet sizes, the arguably more efficient Christensen protocol does not. It is fixed at 132- or the newer 133-byte blocks. This presents a problem at any speed above 300 bps with TAC input buffers defaulted to 64, and it is not so simple to get DCA to make a change for selected ports (it used to take a phone call). At one time there was some work in progress to implement one of several protocols at the TAC level. That effort seems to have died. We feel that such an effort such be revisited due to the proliferation of these PCs and what currently amounts to packet/character file transfers loading the network. Could it be possible that the C/30 TACs currently in use might be upgraded C/30e's? If so, then, depending on the amount of extra memory available, it might be possible to seriously consider implementing the basic protocols of either KERMIT, Christensen, or maybe even X.PC at the TAC level. In any event, we would like to see the input buffer pool on each TAC redistributed to the *active* ports. In many cases, the default input buffer size for each port can be easily raised to 134. With C/30e's it may even be possible to raise that to 1,030 to accomodate the latest variation of the Christensen protocol, without the paperwork to make such a "simple" change request necessary. A low-overhead Christensen transfer would then be possile at higher speeds and thus reduce the duration of such transfers. (I intended to insert a pitch for upgrading the TAC dialin modems to 2,400 bps, but I'm already pushing my luck.) Now, having said all that, are there data to back up our claim that file transfers through TACs are becoming, if not already, a significant factor in network loading to justify a TAC level protocol implementation? --Frank
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 10-Apr-86 17:30:19-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Wollongong problem
Folks, It appears that the Wollongong user TELNET for VMS does not pad the CR (carriage return) with either NUL (idle) or LF (line feed) entered from the keyboard, so is in violation of the TELNET specification (RFC-854, page 10). At least some servers become cranky when faced with "bare" CR, at least in some cases. Fred Ball at Ford noticed the Wollongong struck with the fuzzball TELNET server, but other servers may peal that gong as well. Dave -------
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 Apr 86 02:02:58 est From: karn@mouton.ARPA (Phil R. Karn at mouton.ARPA) To: tcp-ip@sri-nic.arpa Subject: Telnet cr/lf
Clearly, implementations which don't send cr/lf sequences when operating in standard NVT mode are broken. But I assume that the server offers to echo and that the user accepts (as almost all Unix systems do) then the connection reverts to "raw" mode -- otherwise things like screen editors break. Is this a reasonable interpretation? Phil
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 Apr 86 09:53:02 -0500 From: Gurudatta Parulkar <parulkar@dewey.udel.EDU> To: JOHNSON%northeastern.csnet@csnet-relay.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: LAN flooding.
Thank you very much for asking the following question. So let me take this opportunity to elaborate little more of NOAHnet, the flood LAN we are developing. Noahnet uses a graph like topology with 4-5 interconnections per node. It uses a "kind of flooding" to route all data messages around the network and it does not do store and forward. Every node starts forwarding an incoming message to all its UNOCCUPIED adjacent nodes as soon as it receives the first (couple of) bit(s) (one may think of it as a kind of circuit switching). Thus, delay at each node is very small. It uses short status and command messages to release nodes which don't form successful path. In short, our claims are that 1. Graph like topology should provide required reliability to LANs. 2. The topology and our flooding protocol permit multiple messages to be active in the network at any time. 3. Flooding associated with no store and forward provide fast routing strategy. 4. Any thing that you can think of ! Noahnet nodes will be more expensive than other LAN interfaces but not order of magnitude. Flooding looks wasteful, but the modified flooding does not seem to be THAT (?) wasteful. We are doing formal performance analysis to prove (disprove!) these claims. I hope that it gives a better picture of what we are doing. So WHAT DO THINK ?? We do have few tech reports describing the Noahnet effort, in case, you would like to see more details. Thanks for your attention. -guru >>We at University of Delaware are exploring the possibility of using >>flooding in a LAN. Are there any other groups looking into such a >>possibility ? Please send me a note. > Maybe I missed something here. The LANs I know of all have a broadcast > address available to them. Why would you want to flood a LAN when one > packet will do?
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 1986 1059-PST (Friday) From: Barry Leiner <leiner@RIACS.ARPA> To: Mike Muuss <mike@BRL.ARPA> Cc: security@red.rutgers.edu, tcp-ip@sri-nic.ARPA, Ra <root%bostonu.csnet@csnet-relay.ARPA> Subject: Re: Thought on data encryption on networks
Mike, MOst of the work I am aware of in ETE encryption in the internet has been working on top of IP (i.e. encrypts IP packets on a packet by packet basis). Barry ----------
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 Apr 86 08:35 EST From: "Brendan Healey, 0734 752175" <OPERATOR%PSI%REAFSB%SDRRTR%slb-test.csnet@CSNET-RELAY.ARPA> To: apollo@yale.ARPA, info-kermit@cu20b.columbia.edu, info-vax@sri-kl.ARPA, sun-spots@rice.edu, tcp-ip@sri-nic.ARPA, unix-emacs@bbn-unix.ARPA, unix-wizards@brl.ARPA
Hello distribution list!, my name is Brendan Healey, I am the computer centre manager for Fairchild Semiconductor ltd at Reading ENGLAND. I would appreciate it if you would add my name to the distribution list. I have a 8600-11/785 cluster system, attached to the worldwide Schlumberger Information Network, and 4 sun 3/50's. Reading is the site of the European Research, Design and Applications Centre (ERDAC). Our interests range from Pascal to Prolog, C UNIX, SUNS, VAX/VMS and communications. Address being:- system%reafsb%smrvx2%eps731%slb-test.csnet@csnet-relay.arpa Thankyou, Brendan Healey
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 Apr 86 09:31 EST From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA> To: mills@DCN6.ARPA, jas@PROTEON.ARPA, Rudy.Nedved%A.CS.CMU.EDU@SCRC-STONY-BROOK.ARPA, Phil R. Karn at mouton.ARPA <karn@MOUTON.ARPA>, tcp-ip@SRI-NIC.ARPA Subject: Wollongong problem
Time more my yearly TELNET flame: (Implement and) Use SUPDUP.
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 86 15:11:45 mst From: Joe Choy 303-497-1222 <choy%ncar.csnet@CSNET-RELAY.ARPA> To: tcp-ip@sri-nic.ARPA Cc: Subject: EXCELAN EXPERIENCE REFERENCES
I would appreciate anyone who has any expeience with the Excelan board and EXOS software on a VAX VMS system and/or 11/70 running RSX11M+ relating their comments to me. We have users who are considering the products. We are especially interested in problems encountered, support provided by Excelan, compatibility (or the lack of it) with other TCP/IP products, and anything else that might be worth noting. Please reply to me directly: choy@ncar.csnet Thanks in advance!
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 86 16:24:00 MST From: <mgeorge@sandia-2> To: "tcp-ip" <tcp-ip@sri-nic> Subject: VAX 11/750 running Wollengong Software
Here at Sandia Labs, Albuquerque, NM, we recently brought a new host onto MILNET. SANDIA-2 is a VAX 11/750 running VMS and The Wollengong Group IP/TCP software. Our IMP interface is an ACC LH/DH-11. I am looking for VMS procedures to set up and run the following applications: "handle" interpreting for local users' incoming mail "finger" utility bulletin boards: setting up and running distribution lists: setting up and running any other modern conveniences for users and administrators Any help will be appreciated in this area. If anyone has information as to how this configuration of VAX and Wollengong should perform or any bugs detected, I'd be interested. Send responses to: MGEORGE@SANDIA-2 Thanks in advance. - Mike George Division 2633 Sandia National Labs P.O. Box 5800 Albuquerque, NM 87185 505-844- 9357 FTS-844-9357 ------
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 11 Apr 86 14:37 EST From: Rudy.Nedved@A.CS.CMU.EDU To: karn@mouton.ARPA (Phil R. Karn at mouton.ARPA) Cc: tcp-ip@sri-nic.arpa Subject: Re: Telnet cr/lf
The connection only reverts to RAW mode when DO BINARY is done. The normal mode is non-RAW or COOKED depending on what you are using. Interrupt and other special operations characters do not work in RAW mode. RAW tells the terminal driver (whatever flavor) to not act on any characters. CRMOD in non-RAW mode tells the driver to convert from CR to LF since Unix wants "newline" which is a LF. Also CRMOD on output makes LF into CR LF. -Rudy
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 Apr 86 13:22:54 GMT From: Larry Byard <byard@bbncc-eur.ARPA> To: "Frank J. Wancho" <WANCHO@simtel20.arpa> Cc: TCP-IP@sri-nic.arpa, stt-eng@bbncc-eur.arpa Subject: Re: PCs and TACs
Oooops. Make that all IMPs (PSNs) in Europe are C/30Es. There are no C/30E TACs. Larry
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Fri, 11 Apr 86 22:16:18 cst From: jsq@SALLY.UTEXAS.EDU (John Quarterman) To: TCP-IP@SRI-NIC.ARPA Subject: 4.3BSD IP subnet ARP hack
Someone asked a few weeks ago if an ARP hack had been implemented for 4.3BSD. (This is a way to allow subnet gateways to respond to ARP requests for hosts that are on subnets other than the one of the requesting host: the subnet gateway thus becomes a bridge and only subnet bridges need know about subnets.) I have reimplemented Smoot Carl-Mitchell's 4.2BSD ARP hack in 4.3BSD. It is available by anonymous ftp (login anonymous, password guest) from sally.utexas.edu as the shell archive /pub/subarp.shar. I will also post it to mod.sources on USENET, and have sent it to Berkeley.
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 86 0825 PST From: Joe Weening <JJW@SU-AI.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: Telnet binary option
Ah yes, Unix and the Telnet binary option. Most of our hosts at Stanford have been fixed not to interpret this as raw mode, since it's useless for our main use of Telnet, i.e., connecting people's terminals to hosts. Binary mode allow terminals with an "edit" or "meta" key to send this as the 200 bit, which is useful for EMACS and other programs, but terminals continue to send CR when you type <return>, not LF, which is what raw mode expects; and they need both CR and LF to move to the beginning of the next line. Raw mode confuses the hell out of non-Unix hosts. RFC 856 says that both sides need an "interpretation" of binary mode, with no suggestions as to what such an interpretation might be. So I guess it's all right for consenting Unixes to do whatever they want, but when the other host is not known to be Unix, it seems a bit presumptuous to assume it will use Unix conventions. Joe
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 1986 07:59-EST From: CERF@USC-ISI.ARPA To: LYNCH@USC-ISIB.ARPA Cc: narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: Ethernet monitor wanted
Charlie Brown's Complete Systems Inc is reselling a box made by Xerox which does all kinds of tests - including finding breaks in Ethernet cables. This box sells for something like $2-3K I believe. Gary McGreal and Charlie Brown are running this out of Northern Virginia. I will get the phone number if anyone is interested. Vint
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Sat, 12 Apr 86 21:09:26 EST From: "Christopher A. Kent" <cak@Purdue.EDU> To: tcp-ip@sri-nic.arpa Subject: ICMP responses to broadcasts
Let me second John Romkey's assertion that no good ICMP implementation should send redirects in response to a broadcast packet. Might I also ask at this time why our core gateway does just that? We receive several redirects a second in response to the rwho/ruptime packets our Unix hosts send (no ruptime flames, please.) chris
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: Mon, 14 Apr 86 00:19:12 -0800 From: Marshall Rose <mrose@nrtc-gremlin> To: Ra <root%bostonu.csnet@csnet-relay.ARPA> Cc: security@red.rutgers, tcp-ip@sri-nic.ARPA Subject: Re: Thought on data encryption on networks
[ Forgive me for joining so late on this one but I'm inclined to
correct one mistyped fact... ]
> Oh, where is Arthur to slice this gordian knot?
Arthur? It was the Persian boy, "Alexander the Great", who tackled
the Gordian knot. He did not use subtlety but brute force in doing
so.
/mtr
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 1986 07:16-EST From: CERF@USC-ISI.ARPA To: CERF@USC-ISI.ARPA Cc: LYNCH@USC-ISIB.ARPA, narten@PURDUE.EDU tcp-ip@SRI-NIC.ARPA Subject: Re: Ethernet monitor wanted
Complete Systems Inc 3206 Wildmere Place Herndon, VA 22071 (703) 620-5372 for Ethernet Monitors fromCharlie Brown (redistributing Xerox product)
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 1986 1132-PST (Monday) From: Jeff Mogul <mogul@su-navajo.arpa> To: "Christopher A. Kent" <cak@Purdue.EDU> Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: ICMP responses to broadcasts
Let me second John Romkey's assertion that no good ICMP implementation
should send redirects in response to a broadcast packet. Might I also
ask at this time why our core gateway does just that? We receive
several redirects a second in response to the rwho/ruptime packets
our Unix hosts send (no ruptime flames, please.)
Maybe it's because your Unix host is sending broadcasts to the wrong
IP address? (That is, Net.0.0.0 instead of Net.255.255.255)
Of course, it would be nice if gateways looked at the
data-link header to see if something arrived as a broadcast, but
this is one of those little things that is impossible in some systems
(e.g., 4.3), which is why these systems really are unsuited for
use as gateways.
One would hope that the core gateways are capable of handling this, but
I would not be surprised if they are not.
I would also be unsurprised if the core gateways still know nothing
at all about broadcasts. Perhaps someone can fill us in.
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: Mon, 14 Apr 86 09:02:57 EST From: law%h-sc4@harvard.HARVARD.EDU To: CERF@USC-ISI.ARPA, LYNCH@USC-ISIB.ARPA Cc: narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: Ethernet monitor wanted
Yes, would be interested in further info regarding ethernet monitors. Lew Law
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: Mon, 14 Apr 86 09:46 EST From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: Data after a FIN
We are noticing several hosts (e.g., UTAH-CS) that are sending a FIN, then sending data, and finally a second FIN. Technically, The spec says this should happen and the data should be discarded. What I want to know is - Who is doing this (I suspect 4.3BSD)? and - Why? and - Why doesn't anybody else know about it? I was under the impression this list was a clearing-house for ideas, but have absolutely no recollection of this being discussed.
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: Mon 14 Apr 86 14:42:35-EST From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU> To: OPERATOR%PSI%REAFSB%SDRRTR%slb-test.csnet@CSNET-RELAY.ARPA, apollo@YALE.ARPA, info-kermit@CU20B.COLUMBIA.EDU, info-vax@SRI-KL.ARPA, sun-spots@RICE.EDU, tcp-ip@SRI-NIC.ARPA, unix-emacs@BBN-UNIX.ARPA, unix-wizards@BRL.ARPA Cc: JNC@XX.LCS.MIT.EDU
Does anyone know of a 'suitable' tool (definition of exactly what such a tool should do purposely left unstated) to apply to people like this? The polite 'education' method of informing people (which I was a believer in for a while) that this is not a sociable thing to do always seems to miss a few newcomers who promptly make the same mistake. My current theory (regressing to 17th century penal ideology) is that we should punish the offendors so horribly that word of what happens to you when you do this will become instant network folklore. I used to send such pinheads a few megabytes of mail manually, but maybe a tool that sends them 253 copies of SF-LOVERS every hour for three weeks is the right thing. Noel -------
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 Apr 86 6:08:36 EST From: Mike Muuss <mike@BRL.ARPA> To: Hostmaster@sri-nic.arpa, tcp-ip@sri-nic.arpa Cc: Unix-Wizards@BRL.ARPA, GouldBugs@BRL.ARPA Subject: Host table & 4.2BSD problem
The version of /etc/htable distributed with 4.2 BSD, when applied to
the very latest host table from the NIC, fills your disks with
the word "bucsa" repeated over and over again.
The offending new host entry is:
HOST : 192.12.185.1 : BU-CS.BU.EDU,BU-CS.ARPA,BU-CS,BUCSA,A : SUN-3 : UNIX ::
This is currently the only host in the table with a single character
name, and the 4.2 BSD version of "htable" has a (defective) special
case in the handling of this. Never fear, the 4.3 version is correct,
but you don't have it yet.
SUGGESTIONS:
1) The NIC should probably remove the alias "A" from BUCSA. (*I* won't
forget that host name anytime soon -- it's etched on 200 Mbytes of disk!)
2) All UNIX caretakers should apply the following patch to
file /usr/src/etc/htable/scan.l:
From:
{ALPHA} return (NAME);
To:
{ALPHA} {
yylval.namelist = newname(yytext);
return (NAME);
}
Note that Gould UTX 1.2 has this bug as well (a faithful port of the
Berkeley bug). All you folks with binary systems, file an SPR.
Bugs!
-Mike
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 Apr 86 6:39:04 EST From: Mike Muuss <mike@BRL.ARPA> To: Hostmaster@sri-nic.arpa Cc: tcp-ip@sri-nic.arpa Subject: Bad host entries
Turns out that there is more fun. The Berkeley HTABLE program will not accept CPUs of the form: SUN-2/50,they must instead be written SUN2-50. No slashes. There are 5 such er