|
|
ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for September 1984 (63 messages, 32303 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/09.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Fri, 7 Sep 84 2:07:22 EDT From: Doug Kingston <dpk@BRL-AOS.ARPA> To: tcp-ip@sri-nic.ARPA Subject: Gateway Routing Problems
I have been noticing recently that several sites on the ARPANET are frequently if not entirely unreachable from MILNET or nets behind a gateway to the MILNET. My quick sample of the UNIX sites on ARPANET tonight showed the following hosts/gateways displaying less than optimal performance: cornell: accessible from MILNET, but not BRLNETs ll-xn: accessible momentarily from MILNET (3 packets, then it died.) ut-ngp: not accessible from MILNET or BRLNETs utah-cs: not accessible from MILNET or BRLNETs Tests were run by using the Mike Muuss "ping" program, 64 byte packets from BRL-VGR (192.5.21.6), BRL-AOS (26.0.0.29), and SEISMO (10.0.0.25). I suspect there are some serious bugs in the EGP code I suspect these sites are running. Is it possible for them to also use "default" routing a well as the EGP stuff? Comments? -Doug-
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Fri, 7 Sep 84 10:20:57 edt From: cu-arpa.bill@Cornell.ARPA (William A. Nesheim) To: dpk@BRL-AOS.ARPA, tcp-ip@sri-nic.ARPA Cc: egp-people@bbn-unix.ARPA Subject: Re: Gateway Routing Problems
The odd thing is that I am logging all EGP packets and BRLNET1 is deleted after the route timeout interval because no reachability information is recieved within the poll interval! It seems that our EGP neighbor, (currently isi-gateway) does not know how to get to BRLNET1! But, if I add it manually, useing "route add brlnet1 isi-gw 2", I can get there. There appears to be a gap between isi-gw's EGP tables and it's REAL routeing tables. I guess Kirton's assumption that "The default gateway will not know any more routeing information than learned via EGP." is not correct, at least in this case. Bill
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Sun, 9 Sep 84 19:33:20 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: "William A. Nesheim" <cu-arpa.bill@CORNELL.ARPA> Cc: dpk@BRL-AOS.ARPA, tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA Subject: Re: Gateway Routing Problems
The fact that the default gateway will not know any more routing information than EGP can tell you is a fallacy. BBN is using two (let me make it descriptive) turkey gateways for EGP. The core routing information is frequently communicated badly to the EGP gateways. This is all a result of not letting the EGP deadline slip despite the fact that the core system was not ready to handle the cutover. -Ron
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 9 Sep 1984 22:20:38 EDT From: MILLS@USC-ISID.ARPA To: ron@BRL-TGR.ARPA, cu-arpa.bill@CORNELL.ARPA Cc: dpk@BRL-AOS.ARPA, tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA, MILLS@USC-ISID.ARPA Subject: Re: Gateway Routing Problems
In response to the message sent Sun, 9 Sep 84 19:33:20 EDT from ron@brl-tgr.arpa Ron, Your comments on the inadequacies of the EGP core are probably unfair. As you know, EGP support was built on top of an existing GGP implementation that BBN has continuously evolved in response to requirements hardly imagined in the original design. EGP routing information is derived from the same data base used by GGP in these gateways. The GGP routing algorithm requires all peers to communicate simultaneously with all other peers, a model significantly different from EGP and requiring essentially no "third-party" information. Therefore, you can't expect the core to provide optimal routing unless every EGP gateway jabbered with every other GGP and EGP gateway on the common net. Obviously, this model is flawed and should be put right when the new gateway system comes up. Meanwhile, absent brain damage, which seems to be the case for the current problems, we should be able to live with the extra hop and/or redirect (?). Your comment that the core was not ready for the transition was also unfair. The transition actually went surprisingly smoothly, considering the delicacy of the configuration, and easier by far than the 32 -> 96-bit ARPANET leader and NCP -> TCP transitions. Remember, the EGP code had been running smoothly with our gateway for almost a year before the transition, during which a lot of potential problems were detected and fixed. Now that EGP seems to be reasonably chawed and slid down the gullet, let's plan for its successor. We all know it doesn't have the right dynamics for VAN paths. We need to put the fragmentation issue to bed, and as for wiretapping... Dave -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 1984 0902-PDT (Monday) From: karels%ucbarpa@Berkeley (Mike Karels) To: Ron Natalie <ron@brl-tgr.ARPA> Cc: dpk@brl-aos.ARPA, tcp-ip@sri-nic.ARPA, egp-people@bbn-unix.ARPA, "William A. Nesheim" <cu-arpa.bill@cornell.ARPA> Subject: Re: Gateway Routing Problems
I must agree with Ron about the poor quality of routing information obtained with EGP. Our previous "dumb" gateway at Berkeley never used bbn-milnet-gw for MIT and Stanford, nor for milnet or points beyond; our routing was compiled from hosts.txt. And as EGP limits "stub" gateways to representing one network, no flexibility is gained over the previous static entries for the dumb gateways. Mike Karels
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Mon 10 Sep 84 13:18:32-EDT From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: karels%ucbarpa@UCB-VAX.ARPA, ron@BRL-TGR.ARPA Cc: dpk@BRL-AOS.ARPA, tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA, cu-arpa.bill@CORNELL.ARPA, JNC@MIT-XX.ARPA Subject: Re: Gateway Routing Problems
Let me say that in the case of Stanford this may be because their GW does not yet implement EGP. However, if your gateway is not going to MIT direct, then something (algorithm/protocol/implementation - see previous message) is clearly doing something silly. -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 1984 18:14:23 PDT From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: Idea: Authentication Server
Request for Comments: <RFC> 08/01/84
Mike StJohns TPSC
Authentication Server
This RFC suggests an idea for a protocol for the ARPA-Internet
community. Comments and suggestions are solicited and may be
sent via netmail to "StJohns@MIT-MULTICS" or by regular mail to:
Capt Michael C. StJohns
Teleprocessing Services Center
TPSC/TPJS, Pentagon, rm 1D1039
Washington, DC 20330
INTRODUCTION
The Authentication Server Protocol provides a means to determine
the identity of a user of a particular TCP connection. Given a
TCP port number pair, it returns a character string which
identifies the owner of that connection on the server's system.
Suggested uses include automatic identification and verification
of a user during an FTP session, additional verification of a TAC
dial up user, and access verification for a generalized network
file server.
This is a connection based application on TCP. A server listens
for TCP connections on TCP port <PORT>. Once a connection is
established, the server reads one line of data which specifies the
connection of interest. If it exists, the system dependent user
identifier of the connection of interest is sent out the
connection. The service closes the connection after sending the
user identifier.
RESTRICTIONS
Queries are permitted only for fully specified connections. The
local/foreign host pair used to fully specify the connection are
taken from the query connection. This means a user on Host A may
only query the server on Host B about connections between A and
B.
QUERY/RESPONSE FORMAT
The server accepts simple text query requests of the form
<local port>,<foreign port>
where <local port> is the TCP port (decimal) on the target
(server) system, and <foreign port> is the TCP port (decimal) on
the source (user) system.
The response is of the form
Request for Comments: <RFC> 08/01/84
Mike StJohns TPSC
<local port>,<foreign port> : <response type> : <additional
info>
where <local port>,<foreign port> are the same pair as the query,
<response type> is a keyword identifying the type of response,
and <additional info> is context dependent.
RESPONSE TYPES
A response can be one of two types:
USERID In this case, <additional info> is the printable
representation of the user identifier of the owner of
the connection. The format of the returned user
identifier is completely system dependent.
ERROR For some reason the owner of <TCP port> could not be
determined, <additional info> tells why. The following
are suggested values of <additional info> and their
meanings.
INVALID PORT Either the local or foreign port was
improperly specified.
NO USER The connection specified by the port
pair is not currently in use.
UNKNOWN ERROR Can't determine connection owner; reason
unknown.
Other values may be specified as necessary.
CAVAETS
Unfortunately, the trustworthiness of the various host systems
that might implement an authentication server will vary quite a
bit. It is up to the various applications that will use the
server to determine the amount of trust they will place in the
returned information. It may be appropriate in some cases
restrict the use of the server to within a locally controlled
subnet.
APPLICATIONS
1) Automatic user authentication for FTP
2) Verification for privileged network operations. For example,
having the server start or stop special purpose servers.
DISCLAIMER
I designed this protocol to allow me to eliminate the bother of
having to identify myself before continuing an FTP session.
Request for Comments: <RFC> 08/01/84
Mike StJohns TPSC
Since I started work on it, other applications appeared. I have
tried to consider all of our applications while still making this
as general as possible.
-------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 1984 19:03:50 PDT From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: idea: simple file transfer protocol
SFTP
Simple File Transfer Protocol
August 1984
Mark K. Lottor
Laboratory for Computer Science
Massachusetts Institute of Technology
RFC draft Simple File Transfer Protocol
The purpose of this RFC draft is to focus discussion on particular
problems in the ARPA-Internet and possible methods of solution. No
proposed solutions in this document are intended as standards for the
ARPA-Internet. Rather, it is hoped that a general consensus will emerge
as to the appropriate solution to such problems, leading eventually to
the adoption of standards. Distribution of this memo is unlimited.
SFTP is a simple file transfer protocol. It fills the need of people
wanting a protocol that is more useful than TFTP but easier to implement
(and less powerful) than FTP. SFTP supports user access control, file
transfers, directory listing, directory changing, file renaming and
deleting.
SFTP can be implemented with any reliable 8-bit byte stream oriented
protocol, this document describes its TCP specification. SFTP uses only
one TCP connection, whereas TFTP uses a UDP connection and FTP uses two
TCP connections, one using the TELNET protocol.
SFTP is used by opening a TCP connection to the remote hosts' SFTP port.
You then send SFTP commands and wait for replies. SFTP commands sent to
the remote server are always 4 ASCII letters (of any case) followed by a
space, the argument(s), and a <NULL>. The argument can sometimes be
null in which case the command is just 4 characters followed by <NULL>.
Replies from the server are always a response character followed
immediately by an ASCII message string terminated by a <NULL>. A reply
can also be just a response character and a <NULL>.
<command> := <cmd> [<SPACE> <args>] <NULL>
<cmd> := { USER ! ACCT ! PASS ! TYPE ! LIST ! CDIR
KILL ! NAME ! DONE ! RETR ! STOR }
<response> := <response-code> [<message>] <NULL>
<response-code> := { + | - | # | ! }
<message> can contain <CRLF>
Commands that can be sent to the server are listed below. The server
replies to each command with one of the possible response codes listed
under each message. Along with the response, the server should
optionally return a message explaining the error in more detail.
Example message texts are listed but do not have to be followed. All
characters used in messages are ASCII 7-bit with the high-order bit
zero, in an 8 bit field.
The response codes and their meanings:
+ Success.
- Error. An error occurred while processing your command.
# Number. The number-sign is followed immediately by
ASCII digits representing a decimal number.
! Logged in. You have sent enough information to be able
to log yourself in. This is also used to mean you have
sent enough information to connect to a directory.
RFC draft Simple File Transfer Protocol
To use SFTP you first open a connection to the remote
SFTP server. The server replies by sending either:
+MIT-XX SFTP Service
(the first word should be the host name)
-MIT-XX Out to Lunch
If the server send back a '-' response it will also close
the connection, otherwise you must now send a USER command.
USER user-id
Your userid on the remote system. The reply to this
command will be one of:
!<user-id> logged in
(Meaning you don't need an account or password
or you specified a user-id not needing them.)
+User-id valid, send account and password
-Invalid user-id, try again
If the remote system does not have user-id's then you
should send an identification such as your personal name
or host name as the argument, and the remote system would
reply with '+'.
ACCT account
The account you want to use (usually used for billing)
on the remote system. Valid replies are:
!Account valid, logged-in
(Account was ok or not needed. Skip the password)
+Account valid, send password
(Account ok or not needed. Send your password next)
-Invalid account, try again
PASS password
!Logged in
(Password is ok and you can begin file transfers.)
+Send account
(Password ok but you haven't specified the account.)
-Wrong password, try again
RFC draft Simple File Transfer Protocol
You cannot specify any of the following commands until you
receive a '!' response from the remote system.
TYPE { A | B }
The byte size the server should use when receiving files.
The default is Binary if TYPE is not specified.
{
A(scii).
If you are sending the file to the server, the server
system should store the file as 7-bit bytes. If the
system does not have 7-bit bytes it should store it
in an 8-bit byte.
When receiving a file from the server, the server should
know whether the file is 7 or 8 bits and in either case
should send the file with the bytes in an 8-bit field.
B(inary).
The file should be stored and retrieved in 8-bit bytes.
}
Replies are:
+Using { Ascii | Binary } mode
-Type not valid
LIST { F | V } directory-path
A null directory-path will return the current connected
directory listing.
{
F specifies a standard formatted directory listing.
An error reply should be a '-' followed by the
error message from the remote systems directory
command. A directory listing is a '+' followed
immediately by the current directory path specification
and a <CRLF>. Following the directory path is a single
line for each file in the directory. Each line is just
the file name followed by <CRLF>. The listing is
terminated with a <NULL> after the last <CRLF>.
V specifies a verbose directory listing. An error
returns '-' as above. A verbose directory listing
is a '+' followed immediately by the current directory
path specification and a <CRLF>. It is then followed by
one line per file in the directory (a line ending in <CRLF>).
The line returned for each file can be of any format. Possible
information to return would be the file name, size, protection,
last write date, and name of last writer.
}
RFC draft Simple File Transfer Protocol
CDIR new-directory
This will change the current working directory on the
remote host to the argument passed. Replies are:
!Changed working dir to <new-directory>
-Can't connect to directory because: (reason)
+directory ok, send account/password
If the server replies with '+' you should then send an
ACCT or PASS command. The server will wait for ACCT or
PASS commands until it returns a '-' or '!' response.
Replies to ACCT could be:
!Changed working dir to <new-directory>
+account ok, send password
-invalid account
Replies to PASS could be:
!Changed working dir to <new-directory>
+password ok, send account
-invalid password
KILL file-spec
This will delete the file from the remote system.
Replies are:
+<file-spec> deleted
-Not deleted because (reason)
NAME old-file-spec
Renames the old-file-spec to be new-file-spec on the
remote system. Replies:
+File exists
-Can't find <old-file-spec>
(NAME command is aborted, don't send TOBE)
If you receive a '+' you then send:
TOBE new-file-spec
The server replies with:
+<old-file-spec> renamed to <new-file-spec>
-File wasn't renamed because (reason)
DONE
Tells the remote system you are done.
The remote system replies:
+ (the message may be charge/accounting info)
and then both systems close the connection.
RFC draft Simple File Transfer Protocol
RETR file-spec
Requests that the remote system send the specified file.
Receiving a '-' from the server should abort the RETR
command and the server will wait for another command.
The reply from the remote system is:
#<number-of-bytes-that-will-be-sent> (as ascii digits)
-File doesn't exist
You then reply to the remote system with:
SEND (ok, waiting for file)
STOP (You don't have enough space to store file)
The file is then sent as a stream of exactly the number
of 8-bit bytes specified. When all bytes are received
control passes back to you (the remote system is waiting
for the next command). If you don't receive a byte within
a reasonable amount of time you should abort the file
transfer and close the connection.
STOR { NEW | OLD | APP } file-spec
Tells the remote system to receive the following file
and save it under that name. Receiving a '-' should abort
the STOR command sequence and the server should wait for
the next command.
{
NEW specifies it should create a new generation of the file
and not delete the existing one. Replies could be:
+File exists, will create new generation of file
+File does not exist, will create new file
-File exists, but system doesn't support generations
OLD specifies it should write over the existing file, if any,
or else create a new file with the specified name.
+Will write over old file
+Will create new file
(OLD should always return a '+')
APP specifies that what you send should be appended to the
file on the remote site. If the file doesn't exist it will
be created. Server replies:
+Will append to file
+Will create file
(APP should always return a '+')
}
You then send:
SIZE <number-of-bytes-in-file> (as ASCII digits)
where number-of-bytes-in-file is the exact number of
8-bit bytes you will be sending. The remote system replies:
+ok, waiting for file
-Not enough room, don't send it
You then send the file as exactly the number of bytes
specified above. When you are done the remote system
should reply:
+Saved <file-spec>
-Couldn't save because (reason)
You are then ready to send another command to the remote host.
RFC draft Simple File Transfer Protocol
An example file transfer. 'S' is the sender, the user process.
'R' is the reply from the remote server. Remember all server
replies are terminated with <NULL>. If the reply is more than
one line each line ends with a <CRLF>.
R: (listening for connection)
S: (opens connection to R)
R: +MIT-XX SFTP Service
S: USER MKL
R: +MKL ok, send password
S: PASS foo
R: !MKL logged in
S: LIST F PS:<MKL>
R: +PS:<MKL>
Small.File
Large.File
S: LIST V
R: +PS:<MKL>
Small.File 1 69(7) P775240 2-Aug-84 20:08 MKL
Large.File 100 255999(8) P770000 9-Dec-84 06:04 MKL
S: RETR SMALL.FILE
R: #69
S: SEND
R: This is a small file, the file is sent without
a terminating null.
S: DONE
R: +MIT-XX closing connection
-------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 1984 20:11:58 PDT From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: re: Idea: Authentication Server
One suggestion already submitted (by Hedrick) is to have a version of this server that operates on a transaction basis on top of UDP instead of TCP. --jon. -------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 10 Sep 1984 23:39:39 EDT From: MILLS@USC-ISID.ARPA To: karels%ucbarpa@UCB-VAX.ARPA, ron@BRL-TGR.ARPA Cc: dpk@BRL-AOS.ARPA, tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA, cu-arpa.bill@CORNELL.ARPA, MILLS@USC-ISID.ARPA Subject: Re: Gateway Routing Problems
In response to the message sent 10 Sep 1984 0902-PDT (Monday) from karels%ucbarpa@ucb-vax.arpa Mike, You are correct in that the present core system can provide suboptimal routes resulting in an additional hop. Hopefully, that will be fixed soon. You are incorrect in that EGP limits "stub" gateways to only a single network. On the contrary, the official spec RFC-904 allows you to advertise anything you like, as long as all gateways you advertise belong to your AS and only your AS and, in addition, none of the nets you advertise as reachable are advertised by any other AS. Admittedly, the constraints on allowable topolgies have drifted over time, but have tended to become more liberal. So far, our problems have tended to arise from too little connectivity, rather than too much. Dave -------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 11 Sep 84 02:02:51 EDT From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: POSTEL@USC-ISIF.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: idea: simple file transfer protocol
I would be curious to know the motivation of the SFTP proposal. I can imagine some myself, e.g. the desire to have transparent file access, where the file access protocol will have to be built into a device driver. FTP seems to be a bit complex to put into a device driver. Is that what you had in mind? If so, it would seem that a protocol that allows random access might be more useful. I have in mind something more like LEAF (part of the PUP protocols). -------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 Sep 84 12:38:09 pdt From: (Mike O'Dell[x-csam]) mo@lbl-csam To: postel@usc-isif Cc: tcp-ip@sri-nic Subject: SFTP
I see the SFTP proposal as a good one. The current FTP is, I think, overly complex for what most people want to do. SFTP seems to do the right amount of stuff - just move the data and get out of the way. All the conversion and formatting stuff in FTP is wonderful, but very seldom used (and even more infrequently implemented) in my experience. SFTP provides all the services I have ever used in FTP. This protocol also avoids the famous close-the-data-connection dance. I would even go so far as think about replacing FTP with this protocol in the "basic minimal functionality" set. You could then run a file transfer protocol on personal computers which can only handle one TCP connection at a time, which is all that is needed to be a remote terminal. I suspect the IBM PC TCP/IP implementation at MIT is in fact the motivation (since it only supports one TCP connection). -Mike O'Dell
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 Sep 84 13:20 EST From: Mark Scherfling <mrs2%gte-labs.csnet@csnet-relay.arpa> To: tcp-ip@sri-nic.arpa, tcp-ip@brl.arpa Cc: mrs2%gte-labs.csnet@csnet-relay.arpa Subject: TCP/IP-XNS Gateway Information Query
I'm checking out the feasibility of designing a gateway between
TCP/IP and XNS implementations running dissimilar upper-level
protocols, as well as a protocol converter between the two protocols.
Is anyone out there also confronting this problem?
Any information on possible vendor products or unforseen difficulties
would be greatly appreciated. Contact me through the network at the
above address or by telephone at (617) 466-2812. Thanks very much.
John Caddell
GTE Laboratories
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 Sep 84 15:03:31 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: MILLS@USC-ISID.ARPA Cc: ron@BRL-TGR.ARPA, cu-arpa.bill@CORNELL.ARPA, dpk@BRL-AOS.ARPA, tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA, MILLS@USC-ISID.ARPA Subject: Re: Gateway Routing Problems
Dave, I don't fault the existing BBN gateways with the way they operate. I know what it is like stuffing EGP into an existing 11/23 operating system and scrapped our old gateway rather than having to do it (we now use a trivial multitasking operating system that makes full use of the memory management rather than using MOS). My complaint is one of an operational nature which I pointed out before to the ICCB without comment or response. The cutoff date was not realistic. Even though I managed to get a fairly bug-free EGP system on my gateway in the 5 days I was given to test it (BBN did not install EGP on MILNET until the final weeks before the cutover date), the complaints that I put forth are still a problem. It has nothing to do with the EGP protocol nor the routing methodology in the core. The problem is that the number and quality of EGP interfaces. It is my hypothesis that the core gateways that can have EGP stuffed into them, are ones that are not busy doing to much else. This leaves only two MILNET paths to EGP. Both of these gateways are stubs into single, fairly low traffic nets. In at least one time since the cut-over, the BRL complex has been disconnected from the rest of the world because both of those gateways have gone down. One gateway seemed to be suffering from a hardware problem and the other was disconnected because the IMP that it was connected to lost it's ONLY trunk to MILNET. The limitted reliability of these two GATEWAYS and not the core software was what I was referring to when I complained about the CORE not being ready for the EGP changeover. I have asked that more gateways be added that will communicate EGP information to the CORE gateways and that these gateways be added to IMPS that are fairly centralized and well connected. In this way, the rather high level of reliability/redundancy that the MIL/ARPA nets experience would once again be restored. -Ron
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Wednesday, 12 Sep 1984 10:54-PDT From: imagen!geof@su-shasta.arpa To: shasta!TCP-IP@SRI-NIC.ARPA Cc: geof@su-shasta.arpa Subject: Re: idea: simple file transfer protocol
SFTP seems like a nice idea. I have some comments on the spec as presented. First, philosophical. The regular FTP has as one stated goal that users be able to type FTP commands using a telnet-style utility. This implies that control commands should all be in-band, netascii characters. Other file transfer protocols (e.g. TFTP, PupFTP) assume that control commands are generated by machine only and sacrifice mnemonic value for a more regular structure that is easier for programs to handle. SFTP generally seems to follow the first idea, of in-band netascii for control commands. I can think of one application for SFTP's form. That would be to actually use a telnet remote login program (on a different port) to transfer or receive a file, by having options in the program that are similar to those in most serial-line terminal programs -- fill a file from the input stream, dump a file to the output stream. I practise, do we really believe that users will type SFTP commands themselves? I have never heard of anyone connected to an FTP port with Telnet except to test the FTP or to test the TELNET. The free-form nature of control commands in FTP makes it less efficient to implement on some operating systems. For example, to be sure that one reads a line without blocking forever on some systems one must do a system call for every control character. Data structures in the implementation are also more complex for free-form data. I see a cost here without a benefit. Why not use a fixed-form control structure (the application program can always mask this with a free-form front end): Command: +-----------------------------+ | command type | +-----------------------------+ | fixed arg (if needed) | +-----------------------------+ | length of free-form argument| +-----------------------------+ followed by the free-form argument (no termination of it is needed). The fixed argument is appropriate for some commands like TYPE and LIST which have a fixed number of options. The free-form argument is used for other commands (length=0 if not there) like USER and PASS. The command type can be a (mnemonic?) four character constant, or a smaller integer. The response is similar. Note that error strings can be sent as free-form arguments. ======== Other comments on specific points: [1] (picky) The ! option seems unecessary, and is a security violation on some systems. Why not always specify account and password -- the user interface can make this easy to do. This is more consistent for systems that don't have an ACCOUNT concept and would never require it. The rest of the points are not so picky. [2] TYPE: 2.1 What is the default type (suggest A)? 2.2 For type A you should specify a crlf conversion (e.g. NETASCII) otherwise type A is of no value. Think about transfering a file from Unix to Tops-20. 2.3 Between consenting Tops-20's there is no way to transfer all the bits in a file -- type A transfers the bottom 35 and type B the bottom 32 bits of each word. There should also be a type LOCAL which sends data it the way binary data is most conveniently packed on the local system - bitwise on Multics, 8-bit bytes on Unix, 36-bit bytes on tops-20, and so on. The constraint on LOCAL is that a file sent with local mode and re-retreived should be the same (although sometimes it will be longer, if the foreign file systems rounds the length of a file to the block size). I recall discussions of this sort in conjunction with TFTP, so the latest TFTP spec probably indicates the right thing to do. [3] RETR/STOR: SFTP has the same bug that PUP-ftp gets itself into. You try to retrieve a long file, and you can't abort the store/retrieve without reading the entire file. Two simple solutions: [1] reset the connection (inelegant, loses authentication info). [2] do it right (see Courier bulk data transfer option (appendix F)): Use the URGENT pointer of the TCP connection. The recipient of the file can send an urgent pointer followed by an ABORT command. The ABORT command has no effect if no file transfer is in progress, but causes the transfer to abort if file transfer is in effect. The problem is how to re-synchronize the control conversation after an abort. To enable this, divide a file to be transfered into (marked) segments of 512 (or whatever) bytes. The marker for each segment is 1 (continue with next segment). Every segment has 512 bytes, except the last, whose size is determined by the file length (sent as in the spec). The entire file is followed by a marker of 0. The entire process of aborting a file transfer goes as follows: A. Receiver sends URGENT pointer, followed by ABORT command, and discards file records until it sees a marker of 0. B. The Sender receives the URGENT pointer, and discards incoming commands until an ABORT command is received. Then it completes sending the current segment, and sends a marker of 0. Both receiver and sender are now synchronized in the conversant state. The one to communicate next depends on whether the command was a RETR or STOR. ABORT cancels any file transfer commands that have been queued on the TCP connection as well. If the sender does not implement URGENT pointers, the effect is the same, but the entire file must be transmitted only to be discarded at the receiver. Queued commands will still be executed in this case, and the ABORT will be ignored when finally received.
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 Sep 84 06:06:37 pdt From: (Mike O'Dell[x-csam]) mo@lbl-csam To: geof@su-shasta, tcp-ip@sri-nic Subject: SFTP and ascii commands
There are some very good reasons to use readable strings for commands: (1) the cost is minescule (2) the added ease in debugging without having to build some format cracker - just print the traffic Yes, using control characters would work too, but the structure would have to be cracked mentally, at least Human readable ascii is so easy to use and read. As for Twenex's, add a T mode which no one but Twenex's will support. But what about 60-bit machines? Add a C mode so they can send words too?? No, if you want all that stuff, just use the existing FTP. This is designed to be SIMPLER than the current FTP. As for CRLF conversions, again, just send the bytes. This will usually be used between essentially homogeneous system, so don't clutter it up with one more thing to get wrong. And as for TCP Urgent pointers, give me a break! I would hope this simple protocol would be usable on top of ANY reliable 8-bit path. TCP isn't the only transport layer in the universe. As for ABORTS, I would advocate simply closing the connection. If you want to try again, connect again. This doesn't seem to designed for lenghty "remote data shell" sessions (mercifully). If you want all this stuff, use FTP. Yours for simplicity, occassionally at the expense of function, -Mike O'Dell
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Thu 13 Sep 84 08:49:47-PDT From: Mark Crispin <MRC@SU-SCORE.ARPA> To: "(Mike O'Dell[x-csam]) mo"@LBL-CSAM.ARPA Cc: geof@SU-SHASTA.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: SFTP and ascii commands
I agree with Mike O'Dell. Let's not clutter SFTP or it will get complicated. If necessary, have a special data mode to be used between consulting adult operating systems. -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 Sep 84 11:38:06 EDT From: louie@umd5 (Louis Mamakos) To: geof@su-shasta, mo@lbl-csam, tcp-ip@sri-nic Subject: Re: SFTP and ascii commands
I'd sure like to see at least the CR/LF convention to mark the end of a logical line. I doesn't seem like too much extra effort, and would sure be nice for moving my files from my IBM PC to a UNIX system. I'd like to use FTP, but the IBM PC will only do TFTP. Let's keep it simple! Louis Mamakos Univ. of Maryland
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Friday, 14 Sep 1984 10:21-PDT Thursday, 13 Sep 1984 17:02-PDT From: geof@su-shasta.arpa To: shasta!tcp-ip@sri-nic, shasta!mo@lbl-csam Cc: geof@su-shasta.arpa Subject: Re: Re: SFTP and ascii commands
Re: Readable strings -- good point. Re: Local mode -- Please re-read my previous message and note that I did not suggest that MANY new modes be added to SFTP, but that ONE new mode be added. Also note that local mode is effectively what TFTP has, which is purportedly simpler than SFTP (trivial << simple << ?) Re: CRLF conversions -- in SOME sites, MOST files are between different systems, so crlf mapping is important. Again, TFTP does it right, and it adds almost nothing to the code. After all, type ASCII is already there. Re: Aborts - I fail to see what break is needed over urgent pointers. Most stream protocols have some such thing, and it fills an obvious need (because otherwise you need two connections to do FTP right...). But maybe just resetting the connection is better in this case, for simplicity's sake. - Geof
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 Sep 84 20:30:47 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: tcp-ip@sri-nic.ARPA Cc: rbn@BRL-TGR.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
>NOTE: In the current implementation of the core Internet gateways, the >number of networks known to the gateway is limited. The assignment of >this network number does not imply that it is known to the gateways. In >fact, it may not be possible to add this new number to the gateways at >this time due to the current implementation limit. Gee thanks. Here's your network number, no guarantee that you can use it for anything. -Ron
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Fri 14 Sep 84 11:49:09-EDT From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: ron@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA Cc: rbn@BRL-TGR.ARPA, JNC@MIT-XX.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Sounds like the world is ready for subnets. This concept has been discussed before but not offically taken up. Basicialy, if you have a bunch of local nets connected to the rest of the world through a single gateway, the internal structure of that area is not of interest to the rest of the world. A simple way of doing this is to take a single class B number, and divide it up into 'subnets'; to the rest of the world it looks like a single IP network, and only internally is there structure. Several sites with large numbers of local nets, including MIT, Stanford, and CMU, are doing this already. The change to host sofware is minimal, if you keeping routing tables based on ICMP redirects on a per-host fashion. (If you do something fancier in your routing tables, this trick gets harder.) In most host outgoing packet IP code, there is some piece of code that figures out if a host is on a directly attached net or not, and if not routes it to a gateway. This code probably looks something like: if (ip_net_number(packet.ip_dest) == ip_net_number(my_ip_addr)) route_locally(packet, packet.ip_dest); else route_locally(packet, get_ip_gw(packet.ip_dest)); The problem with subnets is that this piece of code needs to be changed so that it knows that just because a host is in the same IP network it may not be possible to get to it directly. A simple scheme exists for doing that. Basically, you have two 32 bit quantities as part of the site file; MY-IP-ADDR and MY-IP-MASK (a mask telling which parts of the address are 'network' number, either simply IP network number of network number plus subnet. At startup, use those two numbers to compute a third, MY-IP-NET, and substitute the following piece of code for the if () statement above: if ((packet.ip_dest & MY-IP-MASK) == MY-IP-NET) This has been done at MIT and works quite well. Jeff Mogul at Stanford is writing a several RFC's to explain the subnet system in use (and planned extensions for automatic routing) at MIT and Stanford; CMU uses a slightly differect scheme. I can answer further questions about how this works if people have sufficient interest, and if there is great demand I guess Jeff could be encourage to finish up the RFC's and release them. Noel -------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Fri, 14 Sep 84 13:45:42 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> Cc: ron@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA, rbn@BRL-TGR.ARPA, JNC@MIT-XX.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Well. Subnets are just fine. The reason we don't do it at BRL (and we did consider it) is obstinate manufacturers (especially BBN). It is not always possible to get at the IP address. However, if you have a bunch of ARP based nets, the problem is not so hard. You just have the gateway have the intelligence and answer the inquiries for hosts that it must play an active role in getting to. -Ron
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 14 Sep 1984 16:23:00 EDT From: MILLS@USC-ISID.ARPA To: egp-people@BBN-UNIX.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Broken EGP songs
Folks, Recently we began having problems similar to those reported recently when EGP "connections" sometimes break with ARPANET and MILNET core gateways. From the data collected by DCN-GATEWAY, it is apparent at least some core gateways send Hello messages to their passive neighbors once per minute. Using the suggested parameters in RFC-904, we send 30 seconds in the initial Request message indicating the minimum polling interval. While the core is perfectly legal in actually polling at a greater interval, what happens is that the number of reachability indications in the window established by the initial polling parameters falls below the minimum, thus the passive neighbor declares the core down. As a temporary fix, I simply upped the 30-second parameter to 45 seconds and things improved. We still see core neighbors break, however, believed due to either gross delays in sending Hello messages or dropped Hellos entirely. The best solution to the problem is for the core to advertise polling parameters in its Confirm messages close to the values it intends to actually use, unless its neighbor wants something slower. The RFC suggests each neighbor use the maximum of its preferred value and its neighbors value. Thus, each neighbor would use the same intervals and the problem would disappear. Dave -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 16 Sep 84 08:54:34 PDT From: Murray.pa@XEROX.ARPA To: Charles Hedrick <HEDRICK@RUTGERS.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: need for a protocol
Good security on Ethernets is very hard. I don't mean good enough to satisfy the spooks. I'm just thinking about things sufficient to stop most hackers. The basic problem is that the coax is a party line. Anybody can listen to anything. Every time you Telnet or FTP from an untrusted workstation, your password is on the coax, in the clear. The ethernet interfaces on most modern workstations can easily be programmed to grab all the packets. In fact, watching the coax (with a third workstation) is a wonderful way to debug protocols. If you have anything like a SUN, you probably already have the software to snoop. That's just the tip of the iceberg. Consider your UDP based suggestion. It can't be too hard to return a fake response to the querry before the real host has generated the real answer. The fun really begins when you consider Trojan horses in Gateways. The only way that I know of to get reasonable security on an ethernet requires encryption. Even that requies a lot of careful thought, or for example, you can record the Login part of a session and replay it later on. I'll send you a copy of the Needham-Schroeder paper if you want a bundle of fine print. Don't get me wrong, I think your proposal is fine. If I had your problem, I'd probably implement something like you suggested. I'm just trying to make sure we don't have too many naive expectations.
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 16 September 1984 16:13-EDT From: David C. Plummer <DCP @ MIT-MC> To: tcp-ip @ SRI-NIC Cc: JNC @ MIT-XX, ron @ BRL-TGR, rbn @ BRL-TGR Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Fri 14 Sep 84 10:51:36-PDT
Date: Fri, 14 Sep 84 13:45:42 EDT
From: Ron Natalie <ron@BRL-TGR.ARPA>
Well. Subnets are just fine. The reason we don't do it at BRL (and
we did consider it) is obstinate manufacturers (especially BBN). It
is not always possible to get at the IP address. However, if you have
a bunch of ARP based nets, the problem is not so hard. You just have
the gateway have the intelligence and answer the inquiries for hosts
that it must play an active role in getting to.
Kludge city here we come!
Isn't the real solution is to implement LRU in the core gateways?
This subnet scheme "may work well at documented sites" but that
doesn't make it easy to modify vendor code. I believe the
Symbolics IP implementation goes through some pains because MIT
has added non-standard items to Internet.
Since I seem to be in a dumping mood... Don't you think it's a
bit late to go adding major changes to the specification. I
mean... you've only had 6(?) years (since 1976?) to straighten
this all out before forcing it on the ARPANET 2 years ago..
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Mon, 17 Sep 84 10:24:42 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: "David C. Plummer" <DCP@mit-mc.ARPA> Cc: tcp-ip@sri-nic.ARPA, JNC@mit-xx.ARPA, ron@BRL-TGR.ARPA, rbn@BRL-TGR.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Excuse me. But what do any of your flames have to do with the message of mine that you forwarded. I have no idea what LRU is and I can't think of installing anything in the core gateways (as they exist now) that is going to help things any. And where did I propose changing any SPEC. ARP is already THE way to handle ethernet based class B/C networks. ARP is outside the TCP/IP specs because it is part of the local net layer (below IP) that resolves local net routing. A similar change would be for BBN to change the routing algorithm in the IMPs. -Ron
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 17 September 1984 10:44-EDT From: David C. Plummer <DCP @ MIT-MC> To: ron @ BRL-TGR Cc: DCP @ MIT-MC, JNC @ MIT-XX, tcp-ip @ SRI-NIC, rbn @ BRL-TGR Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Date: Mon, 17 Sep 84 10:24:42 EDT
From: Ron Natalie <ron@BRL-TGR.ARPA>
Excuse me. But what do any of your flames have to do with the
message of mine that you forwarded.
Note I To:ed tcp-ip and CC:ed everybody else. You were proposing
a bypass operation to the routing methods, yes?
I have no idea what LRU is
and I can't think of installing anything in the core gateways
(as they exist now) that is going to help things any. And where
did I propose changing any SPEC. ARP is already THE way to handle
ethernet based class B/C networks. ARP is outside the TCP/IP specs
because it is part of the local net layer (below IP) that resolves
local net routing. A similar change would be for BBN to change the
routing algorithm in the IMPs.
LRU is Least Recently Used. The core gateways, when they are
asked to route for a subnet not in their tables should flush an
entry and ask some higher authority what the routing path is.
Were you not proposing that non-core gateways, in particular
gateways you had control over the source code, manage to pretend
to know how to get to another subnet by responding to certain ARP
requests? That's not the way to hack local subnets in an
addressing namespace that doesn't support them natively.
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Mon, 17 Sep 84 11:02:29 EDT From: Steven P. Smith <spsmith@BBNCCT.ARPA> To: tcp-ip@sri-nic.arpa Cc: ewolf@bbn-unix.arpa Subject: addition to mailing list
Please add my name to your mailing list. Thank You, Steven P Smith spsmith@bbncct
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Mon 17 Sep 84 11:14:33-EDT From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: ron@BRL-TGR.ARPA Cc: tcp-ip@SRI-NIC.ARPA, rbn@BRL-TGR.ARPA, JNC@MIT-XX.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Using ARP was the solution adopted at CMU. This solution is generally unacceptable since not all networks include ARP. Thus, to include, say, a Pronet in your network system using ARP for subnets you would have to implement ARP on it. Since this is not a manufacturer standard, once again you would have non-standard software in the hosts. (In addition, the particular scheme at CMU has a hairy implementation in the gateways.) -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Mon 17 Sep 84 11:33:02-EDT From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: DCP@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA Cc: ron@BRL-TGR.ARPA, rbn@BRL-TGR.ARPA, JNC@MIT-XX.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
I assume what you meant by 'LRU' was to cache network level entries and give each subnet a class C network number, which would be cached; please be less cryptic in general. There aren't any inherent problems with that approach, but I'm not sure it would scale any better to really large systems (10^5 nets). (The whole advantage of subnets is that it can reduce the amount of useless internal information you have to propogate to the outside world. This would not help a great deal with 10^5 nets, but anytime you can reduce the size of the main problem you can't be far wrong.) You should also know very well (because I told you years ago) that MIT added subnets before there were even class A,B and C addresses; the reason then was that to assign each MIT wire a number would have used up a good portion of the address space. Now, as well all know, and have just seen (which was what started this) giving each wire at MIT (and the other sites that run subnets) a class C number for each is not possible since the routing tables in the PDP11's can't hold the information. (I remain dubious about 68K gateways solving that problem. Once the address space is solved, the transmission and computation load for a huge routing table will remain.) -------
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Mon, 17 Sep 84 11:46:07 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> Cc: ron@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA, rbn@BRL-TGR.ARPA, JNC@MIT-XX.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Fortuantely all our pronets are on systems we can get at the code for. The reason that ARP hacking is handy is that most of the systems that have the code locked up only have ethernet interfaces anyhow. -Ron
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 17 Sep 84 1539 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: J. Noel Chiappa <JNC@MIT-XX.ARPA> Cc: ron@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA, rbn@BRL-TGR.ARPA, JNC@MIT-XX.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
I wish I knew where you were getting your information about CMU's internal networking. Setting the record straight.... 1) CMU does not deal with the routing issue at the moment. We are looking at solutions and currently avoid cycles in the network. 2) We have in use ProNet, 3MB Ethernet and 10MB Ethernet and expect IBM's token ring to show up one of these days. 3) We have in use PUP, XNS, Chaos, IP and some other bizzarre packet and virtual circuit protocols. 4) Given the chaos with hardware and software, the address conversion issue had to be solved. Plummer's ARP seem to be working well at other places and could be extended to non-broadcast mediums by using a well-known host server...so we adopted it. Several local wizards sent mail to TCP-IP discussing networking. 5) CMU expects "all gateways knowing all other gateways" to be a non-working solution in the long term. The idea of "sub-nets" (may be ambiguous) or the better phrase of "hiding network internals" seems like the way to go. The physical ARPANET hides its internal works from external gateways...and seems to work well...the same is done by other groups...the problem is just figuring out how to do cross sub-net routing. -Rudy
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 17 Sep 84 21:28:36 PDT From: DonWinter.pasa@XEROX.ARPA To: David C. Plummer <DCP@MIT-MC.ARPA> Cc: JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA, ron@BRL-TGR.ARPA, rbn@BRL-TGR.ARPA Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
I sometimes wonder if you folks think about how many people you are bickering in front of. How are those of us who are hoping to learn from these lists supposed to interpret these internecene arguments? Don
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 17 September 1984 19:03-EDT From: David C. Plummer <DCP @ MIT-MC> To: JNC @ MIT-XX Cc: DCP @ MIT-MC, tcp-ip @ SRI-NIC, ron @ BRL-TGR, rbn @ BRL-TGR Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
Date: Mon 17 Sep 84 11:33:02-EDT
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
You should also know very well (because I told you years ago)
...
You sure did. And I told you it wasn't in the spec and you said
you were working on proposibg a draft to get in the spec. That
was two (three?) years ago. My point a few messages ago was
"isn't it a little late to solve this problem." Some people
contended long ago this was going to be a problem.
And indeed it is a problem. You win at MIT only because you can
go into the IP layer and juggle some code (or you had it down for
you or on MIT's behalf).
Anyway, you need some way to declare a NET to be subnetted
internally. You can't just say well, this Class A net at MIT is
really subnetted inside but this other class A net over there
isn't. Doing so would CHANGE the specification. That is, how
does a random host plopped down in the middle of nowhere know if
it is subnetted or not? You have to go under the premise that
you cannot modify vendor's code. You're also going to have to
put up with a lot of flak (probably the same type you are getting
from me) from vendors when you tell them 2 years after the ARPA
switchover that the specification is undergoing a non-trivial
change. If you can modify the specification, I probably won't
flame as much. (E.g., if the high bit is on in the octet after
the network number it means that network is subnetted, which only
works for A and B nets, but that's OK.)
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Tuesday, 18 Sep 1984 09:11-PDT From: imagen!geof@su-shasta.arpa To: shasta!tcp-ip@sri-nic, shasta!DCP@MIT-MC Cc: shasta!JNC@MIT-XX, shasta!ron@BRL-TGR, shasta!rbn@BRL-TGR, geof@su-shasta.arpa Subject: Re: Net Num Assignments - JHU-NET1 & JHU-NET2
IMAGEN has offered a TCP option for about 6 months. We offer MIT/Stanford style subnetting (as Noel described in a recent message) as a configuration option (we do not make sources available). I offer this information to show that at least some vendors of TCP are willing to continue to embellish their product, especially when a clear gain can be seen. IMAGEN can amortize a change to TCP for comparitively few sales; other TCP vendors would need more incentive to add a subnetting option to their code. But they would do it, if: [1] they could see a clear benefit to doing it (and they probably could, especially if a subnet routing protocol made better use of LANs than IP-ICMP does. [2] there were a standard to follow. Many networking concerns are now making noises about completely replacing all their current software with the ISO protocols; surely they would be willing to do a little work on TCP to improve its sales. So subnet people, let's get that spec out and adopted! - Geof Cooper IMAGEN
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 18 Sep 84 15:09:43 PDT From: Murray.pa@XEROX.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: Murray.pa@XEROX.ARPA Subject: Subnet specs
I'll add another vote for getting out the subnet specs. Within Xerox, there are several groups interested in IP/TCP. We have several thousand workstations on ~100 ethernets distributed around the country. Our gateways already cope with a mixture of Pup and NS, so adding IP shouldn't be a big deal. It seems clear to me that we can't get 100 class C net numbers in the near future, so the only way to go is to get a single class A net number and do the work ourselves. We would like the results to be compatible with the rest of the world. If somebody will tell us what to do, we will jump on the bandwagon. Otherwise, we'll probably end up brewing up yet another kludge, and sorting things out whenever the subnet spec scene clears.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 18 Sep 1984 16:12-PDT From: BILLW@SRI-KL To: Murray.pa@XEROX Cc: tcp-ip@SRI-NIC Subject: Re: Subnet specs
"it seems clear that we cant get 100 class C net numbers..." This is probably true, but I for one would like to know why. There are 2^21 class C net numbers available, I dont see why a large or diverse organization should not be ablt to request a block of 10 or 100 or more... BillW
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 18 Sep 84 16:53:49 PDT From: Murray.pa@XEROX.ARPA To: BILLW@SRI-KL.ARPA Cc: Murray.pa@XEROX.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Subnet specs
Sorry. My message was misleading. We could probably get 100 class C network numbers. Unfortunately, that wouldn't solve the problem because of the limitations that started this whole discussion. It's possible that the subnet approach isn't really the way to go. If so, will somebody please tell me about the right way. I'm interested in a timescale of a year or so from now rather than 10 years from now.
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 Sep 84 19:52:13 EDT From: Rick Adams <rick@seismo.ARPA> To: BILLW@SRI-KL, Murray.pa@XEROX Cc: tcp-ip@SRI-NIC Subject: Re: Subnet specs
You can get a big block of numbers. When I worked for CCI, I asked for 256 Class-C numbers or a Class-B number that I would subdivide myself. I was given the block of Class-C numbers with no hassles. Did you ask and were refused or are you speculating? ---rick
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 84 09:51 PDT From: Tom Perrine <tom@LOGICON.ARPA> To: TCP-IP@SRI-NIC, UNIX-WIZARDS@BRL Cc: Tom Perrine <tom@logicon> Subject: NSC HYPERchannel
Is anyone out there running a NSC HYPERchannel net with UN*X on a PDP-11 or other DEC equipment? I am looking for just about *any* kind of info on the HYPERchannel. Please send replies directly to me, I will summarize to the net if there is any other interest. Thanks in advance, Tom Perrine Logicon - OSD San Diego, CA
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 19 Sep 1984 11:05:04 PDT From: "Joyce K. Reynolds" <JKREYNOLDS@USC-ISIF.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: Murray.pa@XEROX.ARPA, JKREYNOLDS@USC-ISIF.ARPA Subject: re: Network Number Assignments
Please let me interject for a moment upon on the current wave of these discussions. Many factors must be taken into consideration in the assignment of network numbers. While this process may be considered to be an administrative entity rather than a way to solve the current exchange regarding limitations, subnets, etc., etc., I feel the record should be clarified from this side of the world. Regarding the assignment of network numbers: 1) Please read RFC 900 (J. Reynolds & J. Postel, "Assigned Numbers", June 1984). 2) Jon Postel and I handle the assignment of network numbers for the Internet. 3) Network number assignments may be requested for quantities from one network number to a block of network numbers. 4) In our own contribution to bureaucracy, an application for a network number assignment(s) must be completed. 5) We process the completed applications submitted to us in an objective manner. The door is always open to discussion of prospective network number assignments. Joyce Reynolds -------
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 Sep 84 13:48:15 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: BILLW@SRI-KL.ARPA Cc: Murray.pa@XEROX.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Subnet specs
Especially when getting Class A and B numbers out of the Numbers Czar is like pulling teeth.
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 Sep 84 13:52:11 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: Murray.pa@XEROX.ARPA Cc: BILLW@SRI-KL.ARPA, Murray.pa@XEROX.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Subnet specs
Of course, we could get perverse and talk about supernets which takes lots of Class C numbers and treats them as one net to the outside world. -Ron
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 Sep 84 19:31 EDT From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: hyper-cspace(channel)
We run TCP/IP over a Hyperchannel on Multics. Send mail for details.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 20 September 1984 2104-PDT (Thursday) From: stanonik@nprdc To: tcp-ip@sri-nic Cc: unix-wizards@brl-tgr Subject: rfnm's and 4.2bsd
We have a problem with rfnm counts in 4.2bsd going to 8 during line problems (between our ecu and the imp's ecu) and then never coming down. We are not overriding ecu generated reset. We get the IMPTYPE_RESET message (logged on our console as "interface reset"), but we don't seem to get the IMPTYPE_BADLEADER message (should log on our console as "leader error") which 4.2bsd uses to hostreset, clearing the rfnm counts. Even more puzzling is that manually reseting the ecu doesn't clear the rfnm counts. Again we get the RESET, but not the BADLEADER, so no hostreset. Any ideas? Maybe the imp's not sending BADLEADER? Have any 4.2bsd sites observed BADLEADER in repsonse to manually reseting the ecu? (As an aside, can anyone tell me where the bbn 1822 report specifies when the imp clears it rfnm counts?) Thanks, Ron Stanonik stanonik@nprdc
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Thu 20 Sep 84 22:36:20-PDT From: Mark Crispin <MRC@SU-SCORE.ARPA> To: stanonik@NPRDC.ARPA Cc: tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL-TGR.ARPA Subject: Re: rfnm's and 4.2bsd
It is a horrible idea to test for bad leader. Interface reset should always be used as the condition to "reset everything". My old NCP code for WAITS ignored all messages from the IMP after IMP Ready cycled down until it got an Interface Reset. If it failed to get the Interface Reset within 10 (or was it 30?) seconds after IMP Ready/Host Ready were up, it dropped Host Ready, held it down a few seconds, then tried again. In general, this worked quite well. -------
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 21 September 1984 1409-PDT (Friday) From: stanonik@nprdc To: ron@BRL-TGR.ARPA Cc: MRC@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL-TGR.ARPA Subject: Re: Re: rfnm's and 4.2bsd
According to the bbn 1822 report, after the imp sends a RESET, it should respond to the first message with a BADLEADER. So berkeley's expectation of a BADLEADER seems in accordance with the report. Why they chose to wait for the BADLEADER before clearing rfnm's beats me. Why we don't see a BADLEADER beats me too, and makes it necessary for us to reboot to clear the rfnm counts. The report doesn't seem to mention when the imp clears its rfnm counts. I guess we'll assume on RESET. Thanks, Ron stanonik@nprdc
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Fri, 21 Sep 84 12:37:28 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: Mark Crispin <MRC@SU-SCORE.ARPA> Cc: stanonik@NPRDC.ARPA, tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL-TGR.ARPA Subject: Re: rfnm's and 4.2bsd
Mark is right. The 4.2 IMP reset on Bad leader is horrible. This is obviously derived by watching what happens on IMP reset not by abiding by the rules. BBN may get nasty and fix the IMP so it still obeys the SPEC but doesn't send the BADLEADER. What is probably happening to you is that you are hitting the error count on the ECU and it is the one who is flapping the RELAY at you. The BADLEADER methodology is probably invalid in this situation.
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 1984 1008-PDT (Monday) From: Creon Levit <creon@AMES-NAS-GW.ARPA> To: Tom Perrine <tom@LOGICON.ARPA> Cc: Tom Perrine <tom@LOGICON.ARPA>, TCP-IP@SRI-NIC.ARPA, UNIX-WIZARDS@BRL.ARPA Subject: Re: NSC HYPERchannel
We run the HYPERchannel on our vax 780s under 4.2bsd. The driver (network interface) we use is an update of the 4.2 distribution that was supplied by the original's author, Steve Glaser, at Tektronix. I have fixed it so that is allows "raw" access to the hyperchannel, in addition to tcp/ip access. We use it to talk between vaxes and to talk to our crays. I also have a pdp-11 hyperchannel driver ans a vax system V hyperchannel driver. I would not recommend hyperchannels unless you absolutelt need to talk to machines that dont have ethernet (i.e. Crays, CDC Cybers, IBMs, etc.) ----------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 Sep 84 21:53 EDT From: Mike StJohns <StJohns@MIT-MULTICS.ARPA> To: <@AMELIA-EC.ARPA:creon@AMES-NAS-GW> Cc: Tom Perrine <tom@LOGICON.ARPA>, TCP-IP@SRI-NIC.ARPA, UNIX-WIZARDS@BRL.ARPA Subject: Re: NSC HYPERchannel
What type of things don't you like about the Hyperchannel? Overhead? System load impact? What do you think the advantages of the Ethernet are vs the Hyperchannel? The Air Force Teleprocessing Services Center at the Pentagon is running a TCP Hyperchannel network between 4 Multics computer systems. Its reasonably efficient from our point of view. Mike StJohns (StJohns@MIT-MULTICS.ARPA) (Actually, the above line should read "from their point of view" as I Left there a month ago.)
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 24 Sep 84 23:16:24 EDT From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: EGP
We have just started using our DEC-20 (RUTGERS.ARPA) as a gateway between the Arpanet and our internal Ethernet. Our internal network is currently an extremely simple thing: one cable with a small number of hosts. I do not regard this gateway as being in production, and have not yet asked NIC to set up host entries that would use it. The primary reason is that I'm not sure what to do about EGP. The problem is that DEC does not support EGP on the DEC-20 yet, and apparently it will be some time until they do. The folks at DCA assured me that not everyone supports EGP yet, and they wouldn't be too bothered if we didn't. While it is nice to know that the Marines won't be showing up my doorstep tomorrow, we still need some way of telling the rest of the network that we are here. I have started looking at the relevant RFC's. However it is not yet clear to me whether there is anything I can do short of implementing EGP myself (something I am not anxious to do). We have a Pyramid 90x running 4.2. Presumably the ISI 4.2 code could be ported to it. Would doing so accomplish anything? The Pyramid is of course not our gateway. It could probably be made to appear to be our gateway by the expedient of using a logical host address as RUTGERS-GW, and having the DEC-20 forward any packets sent to the logical address so that they end up on the Pyramid. This doesn't thrill me either, but could be done fairly easily. At the moment a friendly gateway that does support EGP is advertising our network and gateway. (I'm not quite sure what it meant by advertising. I suspect that they simply list us as part of their own autonomous system.) I have a feeling that this is not strictly legitimate. However it is obviously the simplest approach. Is some approach like this going to cause anyone trouble? Does anybody have any good ideas on what we can do until Tops-20 supports EGP? -------
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 Sep 84 13:57:56 EDT From: dca-pgs <dca-pgs@DDN1.ARPA> To: tcp-dig@DDN1.ARPA, hawgs@sri-nic Cc: tcp-ip@sri-nic, info-nets%oz@mit-mc Subject: EDN Magazine - 20 Sep 84 - "NCC Exhibits" Article
(pp.79-96)
Recommended skimming. This is a discussion of the protocol
demos at July's National Computer Conference. The article is
written primarily from a LAN perspective, but is a fairly
cogent short discussion of upper-level protocol issues and
implications thereof of the NCC demos. In particular, it's
a healthy sign that TCP/IP is getting more attentio n from
the trade media. The article discusses the the demo of
the ISO Class 4 Transport Protocol, but unfortunately does
not go into details or scenarios. Re DoD TCP and Xerox XNS,
the article staes that:
"Both the DoD and Xerox developed these protocols
for practical reasons: They wanted a complte set,
including layers 3 and 4, so that they could render
their networks operational. Consequently, even though
the##the NCC demo proved the validity of the ISO Class 4
Transport Protocol, you must still consider other
transport protocols."
I've been waiting for somebody to say that...
The article does have some holes in it; product information
may be inaccurate and should be confirmed, and I have a question
about whether ISO/TP/4 should be chaaracterized as "an extended
subset of the ISO File Transfer Protocol." Still, I think it's
a good short take; it attempts to present the current LAN
upper-level protocol contenders in an even-handed fashion, and
pretty much succeeds.
If anyone can supply more info on the NCC demo, they are
urged to do so. I'm still not sure what conclusions can really
be drawn from the (I presume successful) ISO/TP/4-over-LAN
demo as far as planning for interoperability.
Best,
-Pat Sullivan
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 Sep 84 08:00:54 pdt From: naren <naren%carleton.cdn%ubc.csnet@csnet-relay.arpa> To: tcp-ip%sri-nic.arpa@csnet-relay.arpa Subject: RFC's for IP/TCP
Can you please send me a copy of the RFC's for IP/TCP. Narendra Mehta Systems Engineering Department, Carleton University, Ottawa, Canada ARPA: naren.carleton@ubc
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 Sep 84 9:20:10 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: Mike StJohns <StJohns@MIT-MULTICS.ARPA> Cc: Tom Perrine <tom@LOGICON.ARPA>, TCP-IP@SRI-NIC.ARPA, UNIX-WIZARDS@BRL.ARPA Subject: Re: NSC HYPERchannel
Our HYPERchannel has the annoying habit of dropping itself off line after a power failure and you have to go kick the adapters to get it to come back on. The one good thing about ethernet is that it is passive, and more people support it. No that's two things. The two good things are that it's passive, more people support it, and it's cheaper. No that's three... I'm going with Proteon, I think. Ethernet ain't so great either. -Ron
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 Sep 84 17:18:55 mdt From: nbires!mccallum@lbl-csam (Doug McCallum) To: lbl-csam!"tcp-ip@sri-nic.ARPA"@lbl-csam Subject: NCC demo of ISO/NBS Class 4 Transport layer
The ISO Class 4 Transport Protocol isn't a subset of the ISO File Transfer Protocol. For the purposes of the NCC demo, a subset of the file transfer protocol was run on top of the class 4 transport protocol. A null network layer was used. The ISO protocols will eventually be a complete set of protocols for each layer of the Reference Model. I was present at a number of the planning workshops for the NCC demo. Given the number of vendors that participated and the status of the ISO standards at the time of planning, the demo did a reasonable job of showing compatibility between vendors (at least at the transport layer). There may be future demos given to show interoperability of a more complete network in the future. The European community was also represented by ICL and representatives from ECMA. The demo was primarily designed to show a working transport layer. There were two demos being done - one used IEEE 802.3 based physical layer and the other used IEEE 802.4. The two demos covered the following layers: ISO Layer IEEE 802.3 Demo IEEE 802.4 Demo 7. Application subset of ISO FTP subset of ISO FTP 6. Presentation NULL NULL 5. Session NULL NULL 4. Transport ISO/NBS class 4 ISO/NBS class 4 3. Network NULL NULL 2. Data Link IEEE 802.2 class 1 IEEE 802.2 class 1 1. Physical IEEE 802.3 baseband IEEE 802.4 broadband As the other layers are finalized, vendor products should start to appear. Until then, networks based on currently existing protocols such as TCP/IP and XNS are the only way to go. Another note. NBS has been an active participant in trying to get vendor support for the ISO/NBS protocols. They have set up a protocol testing lab for the purpose of verifying interoperability. All participants at the NCC demo had their transport protocols tested at NBS. (A description of the test facility was given in the March 1984 issue of Data Communications) The NBS specification of the transport differs slightly from the ISO version. Primarily, the NBS specification requires more from a minimum implementation than the ISO spec. An NBS compatible transport should be able to negotiate down to an ISO minimal transport. Is there anyone out there that actually worked on the demo? It would be interesting to hear what problems were encountered. Doug McCallum
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 27 Sep 1984 12:16 PDT From: Art Berggreen <ART@ACC> To: tcp-ip@sri-nic Subject: IEEE 802.4 Hardware
RE: inquiry about IEEE 802.3 Hardware,
The 802.4 modems used in the GM/NBS demo at NCC were made by:
Concord Data Systems
303 Bear Hill Road
Waltham, MA 02154
This is a box which ties to the broadband cable and has an
HDLC link to interface with your host (RS-422/449 interface)
I've also heard that 3M is making 802.4 modems but have no
other info.
<Art@ACC.ARPA>
------
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Sep 84 13:08:17 mdt From: nbires!mccallum@lbl-csam (Doug McCallum) To: lbl-csam!"tcp-ip@sri-nic.ARPA"@lbl-csam Subject: Re: NCC demo
Since a few people asked for a list of vendors at the NCC exhibit, I thought I would give a little more information. The vendors in the NCC exhibit were: 802.4 Allen-Bradley, Concord Data Systems, DEC, Gould, HP, IBM and Motorola Concord Data Systems built the "Token Interface Module" which was used by the other vendors. I think the TIM connects to the host with an HDLC link. 802.3 ACC, Boeing Computer Services, Charles River Data Systems, DEC, Honeywell, HP, ICL, Intel, NBS Institute for Computer Sciences and Technology, and NCR. The 802.4 demo was also used to show GM's MAP (Manufacturing Automation Protocol). IBM's system ran on a Series 1 and was done for GM. Concord Data Systems did a lot of the work associated with the 802.4 standard effort. Concord Data Systems is the only 802.4 product I've seen advertised although there may be others. The product is called "Token/Net". Most of the Ethernet vendors have announced 802.3 compatible controllers and/or tranceivers. Being in the demo does not imply that a vendor has a product, just that they are investigating the protocols and support the standards effort. The above list includes only those vendors that actually participated in the demo. There are other vendors that have sent people to the Transport Workshops but for various reasons did not participate in the NCC demo. Doug McCallum
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Sep 84 12:27:42 EDT From: louie@umd5 (Louis Mamakos) To: tcp-ip@sri-nic Subject: Re: NCC demo of ISO/NBS Class 4 Transport layer
Does anyone know of a vendor that manufactures IEEE 802.4 Broadband hardware? I'd like to do TCP/IP on a broadband coax system, and haven't been able to find hardware to talk to the cable. I'm really looking for some Multibus hardware, but any pointers at all would be helpful. Louis A. Mamakos Computer Science Center - Systems Programming Univ. of Maryland.
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Sep 84 13:27:03 EDT From: dca-pgs <dca-pgs@DDN1.ARPA> To: tcp-ip@sri-nic.arpa, tcp-dig@DDN1.ARPA, hawgs@sri-nic.arpa, info-aos@su-sierra.arpa Cc: dcecusers@DDN1.ARPA, info-unix@brl.arpa Subject: Data General TCP/IP Announcement
Data Communications Magazine, Aug 1984, p.239 "Data General brings Unix, TCP/IP to its Eclipse and DS minicomputers." Data General Corp. announced DG/UX, a native Unix implementation of Berkeley 4.1 software distribution for its Eclipse superminicomputers and Distributed System (DS)) workstations... Programs written ################## In a related announcement, DG released a version of TCP/IP... The company's AOS/VS operating system will support TCP/IP,and hardware will be introduced to support the protocol on Eclipse... (price quotes follow) ------------------------------------------------------------- I have some questions about this TCP/IP venture. 1. What networking applications run on top of the TCP/IP? Are they the typical Arpa suite (FTP, Telnet, SMTP) or something else? 2. Is there a packet-level driver associated with this package (1822 or X.25) or is it confined to LAN's? 3. What are the antecedents of the AOS TCP/IP? Could it have been a porting of 4.1? ------------------------------------------------------------- There's a lot of interest on this end; the AUTOVON/ETS/DSN environment has a lot of DG's. Best, -Pat Sullivan DCEC/DSN
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Sep 84 15:29:00 edt From: God <root%bostonu.csnet@CSNET-RELAY.ARPA> To: info-nets%mit-mc.arpa@CSNET-RELAY.ARPA Subject: U/B Broadband::TCP/IP
We now have an experimental version of the 4.2bsd driver running TCP/IP over Ungermann/Bass Broadband under both UNIX and VMS/Eunice. It seems to work. It is basically a (gross) modification of the U/B driver supplied with the 4.2 tape which was designed for U/B baseband. Besides the broadband hardware from U/B it uses a DR11-W as an interface. Assuming all parties with rights to the software agree we will make it available free of charge to interested parties. We will include how to set up the hardware (which is wrong in all the manuals.) -Barry Shein
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Sep 84 16:21:09 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: dca-pgs <dca-pgs@DDN1.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, tcp-dig@DDN1.ARPA, hawgs@SRI-NIC.ARPA, info-aos@SU-SIERRA.ARPA, dcecusers@DDN1.ARPA, info-unix@BRL.ARPA Subject: Re: Data General TCP/IP Announcement
I sat through a sales presentation for DG TCP/IP. Under their 4 BSD product, they claim they are supporting all that Berkeley did. This includes FTP, TELNET, MAIL, and things like rcp, rsh. I stressed that that is the only way the customers I was representing would buy it. The only interface that they are currently supporting is Ethernet. I again stressed that they must support ARP. I also encouraged them and explained that it would not be that difficult to provide 1822 (Distant Host) and HDH interfaces. As usual, the sales people claimed to be considering it. This is all I know. -Ron
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 Sep 84 20:47:53 EDT From: Doug Kingston <dpk@BRL-TGR.ARPA> To: tcp-ip@sri-nic.ARPA Cc: mo@seismo.ARPA Subject: [Jules P. Aronson: excelan tcp/ip boards]
Can anyone here comment on this letter. If what he says is true and the manuals are correct (no reason to suspect either), then the Excelan boards have some serious problems if they are to be used on the REAL Internet, in short, they won't work. -Doug- ----- Forwarded message # 1: Received: from brl.arpa by BRL-TGR.ARPA id ac01652; 28 Sep 84 18:10 EDT Received: from nlm-gw by BRL-AOS.ARPA id a008488; 28 Sep 84 17:55 EDT Received: by nlm-mcs.ARPA (4.22/4.7) id AA11612; Fri, 28 Sep 84 17:54:26 edt Date: Fri, 28 Sep 84 17:54:26 edt From: "Jules P. Aronson" <aronson@nlm-mcs.ARPA> Message-Id: <8409282154.AA11612@nlm-mcs.ARPA> To: lamas@brl.ARPA Subject: excelan tcp/ip boards Does any one know if it is possible to use the excelan boards on a class C network. We have two boards which were to be used on CODATA 68000 systems to attach them to our ethernet LAN which is a class C network. According to excelan all ethernet lans are class A networks and they accordingly made some assumptions about the permissible network numbers and the host address. According to their documentation only the network number can be set (0-127) and the host address (the remaining 24 bits) is determined by the board address. If anyone has a suggestion other than the scrap these boards, let me know. ----- End of forwarded messages
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Sat, 29 Sep 84 16:24:39 edt From: Chris Maio <chris@columbia> To: dpk@BRL-TGR.ARPA, tcp-ip@sri-nic.ARPA Cc: mo@seismo.ARPA Subject: Re: [Jules P. Aronson: excelan tcp/ip boards]
We got two Excelan boards and ran into the same problem. They are supposed to be sending us new firmware, but I don't know the status. You might want to send mail to hu@columbia-20 and ask him about it, since he's the person trying to track down the problem here. - chris
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |