The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for September 1984 (63 messages, 32303 bytes)
NOTICE: recognises the rights of all third-party works.


Date:      Fri, 7 Sep 84 2:07:22 EDT
From:      Doug Kingston <[email protected]>
To:        [email protected]
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 (, BRL-AOS (, and

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?

Date:      Fri, 7 Sep 84 10:20:57 edt
From:      [email protected] (William A. Nesheim)
To:        [email protected], [email protected]
Cc:        [email protected]
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.

Date:      Sun, 9 Sep 84 19:33:20 EDT
From:      Ron Natalie <[email protected]>
To:        "William A. Nesheim" <[email protected]>
Cc:        [email protected], [email protected], [email protected]
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.

Date:      9 Sep 1984 22:20:38 EDT
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected]
Subject:   Re:  Gateway Routing Problems
In response to the message sent      Sun, 9 Sep 84 19:33:20 EDT from [email protected]


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

Date:      10 Sep 1984 0902-PDT (Monday)
From:      karels%[email protected] (Mike Karels)
To:        Ron Natalie <[email protected]>
Cc:        [email protected], [email protected], [email protected], "William A. Nesheim" <[email protected]>
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
Date:      Mon 10 Sep 84 13:18:32-EDT
From:      J. Noel Chiappa <[email protected]>
To:        karels%[email protected], [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected]
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.
Date:      10 Sep 1984 18:14:23 PDT
From:      [email protected]
To:        [email protected]
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 "[email protected]" or by regular mail to:

     Capt Michael C. StJohns
     Teleprocessing Services Center
     TPSC/TPJS, Pentagon, rm 1D1039
     Washington, DC 20330


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.


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


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

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.


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

     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
     Other values may be specified as necessary.


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


1) Automatic user authentication for FTP

2) Verification for privileged network operations.  For example,
having the server start or stop special purpose servers.


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.

Date:      10 Sep 1984 19:03:50 PDT
From:      [email protected]
To:        [email protected]
Subject:   idea: simple file transfer protocol


                     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

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.
     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.
     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)

   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
R: +MKL ok, send password
S: PASS foo
R: !MKL logged in
R: +PS:<MKL>
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
R: #69
R: This is a small file, the file is sent without
   a terminating null.
R: +MIT-XX closing connection

Date:      10 Sep 1984 20:11:58 PDT
From:      [email protected]
To:        [email protected]
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.

Date:      10 Sep 1984 23:39:39 EDT
From:      [email protected]
To:        karels%[email protected], [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected]
Subject:   Re:  Gateway Routing Problems
In response to the message sent  10 Sep 1984 0902-PDT (Monday) from karels%[email protected] 


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.

Date:      11 Sep 84 02:02:51 EDT
From:      Charles Hedrick <[email protected]>
To:        [email protected]
Cc:        [email protected]
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).

Date:      Tue, 11 Sep 84 12:38:09 pdt
From:      (Mike O'Dell[x-csam]) [email protected]
To:        [email protected]
Cc:        [email protected]
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
Date:      Tue, 11 Sep 84 13:20 EST
From:      Mark Scherfling <mrs2%[email protected]>
To:        [email protected], [email protected]
Cc:        mrs2%[email protected]
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

Date:      Tue, 11 Sep 84 15:03:31 EDT
From:      Ron Natalie <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
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.

Date:      Wednesday, 12 Sep 1984 10:54-PDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   Re: idea: simple file transfer protocol
SFTP seems like a nice idea.  I have some comments on the spec as

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

Date:      Thu, 13 Sep 84 06:06:37 pdt
From:      (Mike O'Dell[x-csam]) [email protected]
To:        [email protected], [email protected]
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
Date:      Thu 13 Sep 84 08:49:47-PDT
From:      Mark Crispin <[email protected]>
To:        "(Mike O'Dell[x-csam]) mo"@LBL-CSAM.ARPA
Cc:        [email protected], [email protected]
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.
Date:      Thu, 13 Sep 84 11:38:06 EDT
From:      [email protected] (Louis Mamakos)
To:        [email protected], [email protected], [email protected]
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
Date:      Friday, 14 Sep 1984 10:21-PDT Thursday, 13 Sep 1984 17:02-PDT
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected]
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

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
Date:      Thu, 13 Sep 84 20:30:47 EDT
From:      Ron Natalie <[email protected]>
To:        [email protected]ARPA
Cc:        [email protected]
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.

Date:      Fri 14 Sep 84 11:49:09-EDT
From:      J. Noel Chiappa <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected], [email protected]
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);
		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
Date:      Fri, 14 Sep 84 13:45:42 EDT
From:      Ron Natalie <[email protected]>
To:        "J. Noel Chiappa" <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected]
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.

Date:      14 Sep 1984 16:23:00 EDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
Subject:   Broken EGP songs

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.

Date:      16 Sep 84 08:54:34 PDT
From:      [email protected]
To:        Charles Hedrick <[email protected]>
Cc:        [email protected]
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.
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 <[email protected]>

    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..
Date:      Mon, 17 Sep 84 10:24:42 EDT
From:      Ron Natalie <[email protected]>
To:        "David C. Plummer" <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected]
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.

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 <[email protected]>

    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.

Date:      Mon, 17 Sep 84 11:02:29 EDT
From:      Steven P. Smith <[email protected]>
To:        [email protected]
Cc:        [email protected]
Subject:   addition to mailing list
Please add my name to your mailing list. 

	Thank You, Steven P Smith

	[email protected]

Date:      Mon 17 Sep 84 11:14:33-EDT
From:      J. Noel Chiappa <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected], [email protected]
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.)
Date:      Mon 17 Sep 84 11:33:02-EDT
From:      J. Noel Chiappa <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected], [email protected], [email protected]
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.)
Date:      Mon, 17 Sep 84 11:46:07 EDT
From:      Ron Natalie <[email protected]>
To:        "J. Noel Chiappa" <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected]
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.

Date:      17 Sep 84 1539 EDT
From:      [email protected]
To:        J. Noel Chiappa <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected]
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 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.

Date:      17 Sep 84 21:28:36 PDT
From:      [email protected]
To:        David C. Plummer <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected]
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?

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 <[email protected]>

    	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.)
Date:      Tuesday, 18 Sep 1984 09:11-PDT
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected]
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
Date:      18 Sep 84 15:09:43 PDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
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.
Date:      18 Sep 1984 16:12-PDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
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...

Date:      18 Sep 84 16:53:49 PDT
From:      [email protected]
To:        [email protected]
Cc:        [email protected], [email protected]
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.

Date:      Tue, 18 Sep 84 19:52:13 EDT
From:      Rick Adams <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected]
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?


Date:      19 Sep 84 09:51 PDT
From:      Tom Perrine <[email protected]>
To:        [email protected], [email protected]
Cc:        Tom Perrine <[email protected]>
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

Date:      19 Sep 1984 11:05:04 PDT
From:      "Joyce K. Reynolds" <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected]
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

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

Date:      Wed, 19 Sep 84 13:48:15 EDT
From:      Ron Natalie <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected]
Subject:   Re:  Subnet specs
Especially when getting Class A and B numbers out of the Numbers
Czar is like pulling teeth.

Date:      Wed, 19 Sep 84 13:52:11 EDT
From:      Ron Natalie <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected], [email protected]
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.

Date:      Wed, 19 Sep 84 19:31 EDT
From:      "Benson I. Margulies" <[email protected]>
To:        [email protected]
Subject:   hyper-cspace(channel)
We run TCP/IP over a Hyperchannel on Multics.  Send mail for details.
Date:      20 September 1984 2104-PDT (Thursday)
From:      [email protected]
To:        [email protected]
Cc:        [email protected]
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?)


Ron Stanonik
[email protected]
Date:      Thu 20 Sep 84 22:36:20-PDT
From:      Mark Crispin <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected]
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.
Date:      21 September 1984 1409-PDT (Friday)
From:      [email protected]
To:        [email protected]
Cc:        [email protected], [email protected], [email protected]
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


[email protected]
Date:      Fri, 21 Sep 84 12:37:28 EDT
From:      Ron Natalie <[email protected]>
To:        Mark Crispin <[email protected]>
Cc:        [email protected], [email protected], [email protected]
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.

Date:      24 Sep 1984 1008-PDT (Monday)
From:      Creon Levit <[email protected]NAS-GW.ARPA>
To:        Tom Perrine <[email protected]>
Cc:        Tom Perrine <[email protected]>, [email protected], [email protected]
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.)

Date:      Mon, 24 Sep 84 21:53 EDT
From:      Mike StJohns <[email protected]>
To:        <@AMELIA-EC.ARPA:[email protected]>
Cc:        Tom Perrine <[email protected]>, [email protected], [email protected]
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 ([email protected])

(Actually, the above line should read "from their point of view" as I
Left there a month ago.)
Date:      24 Sep 84 23:16:24 EDT
From:      Charles Hedrick <[email protected]>
To:        [email protected]
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?
Date:      Tue, 25 Sep 84 13:57:56 EDT
From:      dca-pgs <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected], info-nets%[email protected]
Subject:   EDN Magazine - 20 Sep 84 - "NCC Exhibits" Article

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.

-Pat Sullivan

Date:      Wed, 26 Sep 84 08:00:54 pdt
From:      naren <naren%carleton.cdn%[email protected]>
To:        tcp-ip%[email protected]
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:	[email protected]
Date:      Wed, 26 Sep 84 9:20:10 EDT
From:      Ron Natalie <[email protected]>
To:        Mike StJohns <[email protected]>
Cc:        Tom Perrine <[email protected]>, [email protected], [email protected]
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.

Date:      Wed, 26 Sep 84 17:18:55 mdt
From:      [email protected] (Doug McCallum)
To:        lbl-csam!"[email protected]"@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
Date:      27 Sep 1984 12:16 PDT
From:      Art Berggreen <[email protected]>
To:        [email protected]
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.

    				<[email protected]>

Date:      Thu, 27 Sep 84 13:08:17 mdt
From:      [email protected] (Doug McCallum)
To:        lbl-csam!"[email protected]"@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:
		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.

		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
Date:      Thu, 27 Sep 84 12:27:42 EDT
From:      [email protected] (Louis Mamakos)
To:        [email protected]
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.
Date:      Thu, 27 Sep 84 13:27:03 EDT
From:      dca-pgs <[email protected]>
To:        [email protected], [email protected], [email protected], [email protected]
Cc:        [email protected], [email protected]
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.

-Pat Sullivan

Date:      Thu, 27 Sep 84 15:29:00 edt
From:      God <root%[email protected]>
To:        info-nets%[email protected]
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

Date:      Thu, 27 Sep 84 16:21:09 EDT
From:      Ron Natalie <[email protected]>
To:        dca-pgs <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
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.

Date:      Fri, 28 Sep 84 20:47:53 EDT
From:      Doug Kingston <[email protected]>
To:        [email protected]
Cc:        [email protected]
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.


----- Forwarded message # 1:

Received: from 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" <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
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
Date:      Sat, 29 Sep 84 16:24:39 edt
From:      Chris Maio <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected]
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 [email protected] and ask him about it,
since he's the person trying to track down the problem here.

- chris