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 March 1984 (22 messages, 9646 bytes)
NOTICE: recognises the rights of all third-party works.


Date:      7 Mar 1984 1658 PST
From:      Eric P. Scott <[email protected]>
To:        [email protected]
Subject:   DECUS foulup
"Internetworking the ARPA Way" has been tentatively scheduled for
1:00 p.m. Friday and cut to 1 1/2 hrs. even though I had
specifically requested otherwise.  The "official story" is that
the scheduling constraints on the submission form were never
entered into the online system.  I have asked the Networks
Symposia Coodinator for a reschedule; we'll see what happens.

Date:      10 Mar 84 16:46:59 EST
From:      dca-pgs @ DDN1
To:        allusers @ DDN1, allusers @ ddn2, allpoints @ isi, allusers @ nalcon, allusers @ nems, tcp-ip @ sri-nic, feinler @ sri-nic
Cc:        [email protected], [email protected], [email protected], dca-pgs, ddn-navy
Subject:   DDN Cutover Announcement--Naval Regional Data Automation Center (NARDAC), Washington, DC

Date: 10 Mar 84 15:41:30 EST

On Saturday, 10 Mar 84 (today), the undersigned witnessed a successful
demonstration of NARDAC/WASH's Sperry U1100/62-DCP/40 system operating
over the Defense Data Network, using Sperry's X.25 interface.
The NARDAC/WASH system opened and sustained an X.25 connection with
a similar Sperry system at Naval Data Automation Facility (NAVDAF),
Newport, RI. The NAVDAF/Newport system was cut over to DDN in December 83.
As part of the demo, UTS-20 terminal sessions were set up in both
directions, with Washington terminals "passing-thru" the local Washington
system to access the Newport host computer, and vice versa. This is the
first known use of DDN to support Sperry UTS synchronous terminal sessions,
and is a significant milestone. Other DDN-compatible Sperry capabilities
will be added in coming days. TCP/IP, SMTP, FTP and Telnet will be
retrofitted as they become available.

I would like to take this opportunity to recognize the contribution
of several individuals. The list would have to be headed by 
Rod Richardson, the DCA/DDN-PMO Navy Systems Implementor. It is due
to his tireless efforts that the DCA side of the NARDAC-DDN initiative
took shape. Also crucial to this effort was MAJ(P) Bruce Sweeny and his
DDN/PMO installation team. They, along with Tony Michel and his
counterpart team on the BBN side, put a "crash" effort into readying
the Naval Research Laboratory IMP for the NARDAC/WASH connection.
Susan Poh of MITRE accompanied me to the demo today and again demonstrated
her capacity for generating many valuable ideas and suggestions in a
short period of time.
On the Sperry side, Frank Sweet, Judy England, and Bill Ruegg were
all indispensable to this effort. Finally, I would like to thank all
those on the Navy side; from NAVDAF/Newport, CDR E. Perkins and Mr.
Roy Kirkpatrick; from NARDAC/WASH, Messrs. Ed Grace and Dave Brack;
and from Naval Data Automation Command (NAVDAC), Messrs. Bob Murray,
Chuck Trigger, and Dave Vaughan, all of whom played indispensable roles
with their expertise, initiative, and dedication.

-Pat Sullivan
Forwarded message(s):  
To: dca-pgs @ DDN1
From: dca-pgs @ DDN1
Subject: DDN-NARDAC/Washington Test Observers
Date: 10 Mar 84 15:28:22 EST
cc: dca-pgs @ DDN1

NAME                     ORG'N                        PHONE

David Vaughan            NAVDAC                       433-4671

Bill Ruegg               Sperry                       556-5341

Frank Sweet              Sperry                       556-5341

Ed Grace                 NARDAC/Washington            433-3052

Dave Brack               NARDAC/Washington            433-4033

Pat Sullivan             DCA/DDN/PMO/B616             285-5036

Susan Poh                MITRE                        883-7290

Area Codes: NAVDAC/NARDAC 202, all others 703.

-------------END OF FORWARDED MESSAGE(S)-------------

Date:      13 Mar 1984  7:39:17 EST (Tuesday)
From:      John Swanson <[email protected]>
To:        [email protected]
Subject:   Distribution list
Could you please place me on the distribution list for tcp-ip information.
Thank you.
	John Swanson

Date:      16 Mar 1984 13:39:00 PST
From:      [email protected]
To:        [email protected]
Subject:   Domain Style Names - Coming Soon

An interesting and entertaining thing will happen next Wednesday.

Domain Style Names will become the normal thing for all hosts in the

The Host Tables maintained by the NIC will change to have ".ARPA"
appended to the official name of every host in the table.

This may cause a few programs to have a few problems.  If you want to
try things out prior to Wednesday you can test with the table in the

For more information see DDN MGT Bulletin 22, and RFCs 897 & 881.

Date:      20 Mar 1984 13:14:08 PST
From:      Craig Milo Rogers  <[email protected]>
To:        Ron Natalie <[email protected]>, [email protected]
Subject:   Re: Message-ID Low Order Bits
	Many months ago I wrote an 1822/IP/UDP/TFTP bootstrap for
PDP-11s.  I was quite surprised when the bootstrap could be used
between two ARPANET hosts, or between two MILNET hosts, but not between
an ARPANET host and a MILNET host.  The BBN gateways put a sequence
number in the four low order bits of Message-id.  If someone has an
archive of this mailing list, perhaps you can recover the discussion.

					Craig Milo Rogers
Date:      Tue, 20 Mar 84 12:25:37 EST
From:      Ron Natalie <[email protected]>
To:        [email protected]
Subject:   Message-ID Low Order Bits
In working on the IMP interfaces for the BRL gateway, I was considering
setting a non-zero value in the low order bits of the Message-ID field
in the IMP leader.  I want to do this to identify the control messages
with the original messages as suggested by BBN Report 1822 which states:

   For each regular message, the Host also specifies a 12-bit
   identifier, the message-ID (Until mid-1973 the first eight bits
   of the message-id field were called the "link").  The message-id,
   together with the destination of the message, is used as the name
   of the message.  The IMP will use this name to inform the Host of
   the disposition of the message.  Therefore, if the host refrains
   from reusing a particular message-id value (to a given destination)
   until the IMP has responded about that message-id, messages will
   remain uniquely identified...

Looking at the few versions of IP that we have here, I see that these
bits are totally ignored by the receiving proccess.  However, I am
concerned that some ambitious hosts will not recognize IP packets with
the lower bits set as IP packets.  The justification for rejecting these
comes from the assigned numbers document (RFC790):

    The name link now refers to the high order 8 bits of this 12 bit
    message-id field.  The low order 4 bits of hte message-id field
    are to be zero unless specifically specified otherwise for the
    particular protocol used on that link.

This indicates that since IP doesn't mention these bits at all, I'm not
supposed to fool with them.  Anyone have any reasons why I shouldn't?
Perhaps an official statement "specifically specifying" that these bits
are unspecified and may be set to any value by the transmitting host.

Yes, I know I can kludge around this using the knowledge that messages
are always kept in sequence to a destination provided the handling type
is the same (I assume this also applies to the acknowledgement-RFNM and

Date:      Wed, 21 Mar 84 11:40:53 EST
From:      Ron Natalie <[email protected]>
To:        [email protected], [email protected]
Subject:   Hosttable changes.
Did I miss something like a previous announcement that the changes
were going to be made?  5 days advance notice when two of them are
on the weekend seems a little shabby to me.

Date:      Wed 21 Mar 84 16:35:34-PST
From:      [email protected]
To:        Host-table-distribution: ;
Cc:        [email protected], [email protected], [email protected]
Subject:   New NIC host tables
Beginning on 21 March 84 the NIC will be providing two separate
versions of the Official DoD Internet Host Table.  Both versions will
be available via the NIC Name Server.  The newly added keyword is
ALL-OLD which will get you the host table without the ".ARPA" domain
names.  The old format host table will still be available from the NIC
until 1 May 1984 at least, and possibly longer.

Hosts which are still FTPing the table will find the new "domain"
style table in the file <NETINFO>HOSTS.TXT and its corresponding
binary form in <NETINFO>HOSTS3.BIN.

The old table without the ".ARPA" domain names is <NETINFO>OHOSTS.TXT
with its corresponding binary form available as <NETINFO>OHOSTS3.BIN.

The format of the file <NETINFO>INTERNET.GATEWAYS remains unchanged.

Any questions should be sent to ([email protected]).

- Mary Stahl / NIC
Date:      Mon 26 Mar 84 19:02:12-PST
From:      David Roode <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected], [email protected]
Subject:   DOMAINS.TXT creation
Since we are only a week and a half away from the maintenance of the
top-level domain table, and two months more from the possibility of
introducing new top level domains, I would like to ask if anyone is
considering name servers for the top-level "domains" currently in use
with certain sites' TOPS-20 mail software.

A lot of official business is being conducted via these mail relays,
but nothing has been heard of regarding plans for host name servers.

Some "domains" in use are:

DOMAIN Berknet,%Berkeley.ARPA,Berkeley

Another candidate is:

Date:      27 Mar 84 0231 EST
From:      [email protected]
To:        David Roode <[email protected]>
Cc:        [email protected], [email protected], [email protected], [email protected]
Subject:   Re: DOMAINS.TXT creation

In reference to CCnet-CMU and TLNet "domains":

I expect TLNet to go away since a better connection will soon exist between
Tartan Labs and the ARPANET which will be a full IP link over a 9600 baud
behind CMU-Gateway. The Tartan Lab's machines will therefore look like any
Internet class C host set.

The CCnet-CMU and CCnet-Columbia networks which are basically the same but
differ in which relay allows what hosts to send mail to what node is going to
shrink we hope and become more apart of CMU's Class B network. We expect
CMU-CS-C to stop being a CCNet node shortly and another node on CCNet to take
up the relay load. We also expect this process to continue and shrink the size
of CCNet considerably in the near future.

Therefore I don't think TLNet or CCNet should exist as domains in anybody's
"new" software tables. [The CCNet hosts will probably be contained in either
Columbia's sub-domain name server and/or CMU's sub-domain name server.]

I do however expect CMU to have its own sub-domain as our internal name space
continues up its exponential curve. We have network capable PCs and dedicated
network oriented computers popping up like weeds....

Rudy Nedved
Facilities Staff member
CMU Computer Science/Robotics Institute
Date:      Tue 27 Mar 84 11:04:22-EST
From:      Dan Tappan <[email protected]>
To:        [email protected]
Subject:   Name server implimentations
Is there a later version of the domain name server spec than RFC883?

I get nervous trying to impliment something, which according to the 
schedule is supposed to be operational within a few weeks, based
on a spec with things like this in it

           |                                               |
           |             *****  WARNING  *****             |
           |                                               |
           |  The following format is preliminary and is   |
           | included for purposes of explanation only. In |
           | particular, the size and position of the      |
           | OPCODE, RCODE fields and the number and       |
           | meaning of the single bit fields are subject  |
           | to change.                                    |
           |                                               |

Date:      28 Mar 1984 1010 PST
From:      Scott McCord <[email protected]>
To:        [email protected]
Subject:   Has it been done?
Is anyone  implemented tcp/ip on a host that supports 32
telnet connections simultaneously? Maybe 25?,10?,5?....and how is
performance with that many users?

Any info would be helpful

Scott McCord <SMJPM at JPL-VLSI>
Date:      Thu, 29 Mar 84 14:06:00 EST
From:      Nathaniel Mishkin <[email protected]>
To:        [email protected]
Subject:   Gateways
Sorry if this is rehashing some old topic, or if I'm terrible confused,

At Yale, we have a local IP network YALE-NET (128.36).  On this network
we presently have some Apollos (YALE-RING), a Unix 4.1 + BBN-TCP/IP
VAX (YALE) and a Unix 4.2 VAX (YALE-PENGUIN).  YALE is also on ARPANET
and runs Chris Kent's pseudo-gateway code.

There are a number of non-ARPANET (i.e. non-network 10) sites that
are reachable from from YALE, but not from YALE-RING.  YALE-RING can
in fact communicate with lots of ARPANET and non-ARPANET sites.  It
seems that the problems arise with 4.2 sites (although there could
be others).

From my cursory examination of the 4.2 documentation, it appears that
unlike the BBN TCP/IP network support, the 4.2 support requires that
sites lists all the reachable remote networks and the gateways thereto
in the gateway file.  That is, I didn't see a mechanism for listing
full routing ("prime"?) gateways.  As a result, I have developed the
intuition that there are a number of 4.2 machines out there that simply
list ARPANET in their gateway file and hence do not know how to reach
random local networks like mine.

Can someone tell me what's actually going on?

Please respond to me directly since I am not on this list.  Thanks.

                -- Nat
Date:      Thu, 29 Mar 84 21:40:31 EST
From:      Mike Muuss <[email protected]>
To:        Nathaniel Mishkin <[email protected]>
Cc:        [email protected]
Subject:   Re:  Gateways
4.2 has the notion of a "default route", to be used when no other
routes are explicitly indicated.

To establish a default route, add this command to /etc/rc.local :

/etc/route add 0 gateway-to-use 3

the "0" is for the "default route", and the "3" is a hop metric,
which can be any number > 1.

Date:      Fri, 30 Mar 84 10:55:36 EST
From:      Nathaniel Mishkin <[email protected]>
To:        Mike Muuss <[email protected]>
Cc:        [email protected]
Subject:   Re:  Gateways
    4.2 has the notion of a "default route", to be used when no other
    routes are explicitly indicated.
Thanks very much.  I tried this on our 4.2 system and it had the desired
affect.  The only reference I could find to this feature was a slightly
obscure one in INTRO(4N), and not in ROUTE(8C) or ROUTED(8C) where
I would have expected to find it.  Does anyone know how many other
4.2 sites do not know about it?

            -- Nat
Date:      30 Mar 1984 16:18:41 PST
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected], [email protected], [email protected]
Subject:   Re: DOMAINS.TXT creation
In response to the message sent  Mon 26 Mar 84 19:02:12-PST from [email protected]

David Roode:

the "domains" you list are simply Mark Crispins private hacks in his TOPS20
code.  They are not registered DOMAINs.  The only DOMAIN currently authorized
is "ARPA".

Date:      30 Mar 1984 16:36:13 PST
From:      [email protected]
To:        [email protected], [email protected]
Cc:        [email protected]
Subject:   Re: Name server implimentations
In response to the message sent  Tue 27 Mar 84 11:04:22-EST from [email protected]


Please contact the author of the RFC to get up to date on the current info.
That is Paul Mockapetris = [email protected]

Date:      Fri, 30 Mar 84 15:35:24 cst
From:      [email protected] (John Quarterman)
To:        [email protected]
Cc:        Mike Muuss <[email protected]>, [email protected]
Subject:   Re:  Gateways
I believe the "default route" feature is also mentioned in
"Installing and Operating".
Date:      Fri, 30 Mar 84 15:40 EST
From:      "Benson I. Margulies" <[email protected]>
To:        [email protected]
Subject:   many telnet connection
Multics supports arbitrary numbers of TCP connections.
Date:      Fri 30 Mar 84 20:48:12-PST
From:      David Roode <[email protected]>
To:        [email protected], [email protected]
Cc:        [email protected], [email protected]
Subject:   Re: DOMAINS.TXT creation
I thought operation of a Nameserver was a prerequisite to registration
as a Domain.  This was the light in which I phrased the
Nameserver-in-planning inquiry.  RFC897 seems to state that
Domains other than "ARPA" and "DDN" are going to be allowed as of 6
June 1984.  A month earlier domain "DDN" is scheduled for creation and use
according to RFC897, so software which expects all hostnames to
end in ".ARPA" (not interpreting this as a Domain) needs to be fixed
before then. I didn't mean to imply that Domains should be created
willy-nilly, but that certain existing administrative entities
would seem to lend themselves to identification as a Domain.
The question was meant to be "are any of you working on it?"
Date:      Sat 31 Mar 84 04:30:34-PST
From:      Mark Crispin <[email protected]>
To:        [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected]
Subject:   Re: DOMAINS.TXT creation
     I find myself agreeing with Jon, although I perhaps wouldn't put
it quite the way he did.  The TOPS-20 mailsystem's DOMAINS.TXT
functionality is merely a workaround to fufill a need not presently
supplied by current protocols or standards.  I would hate to see it
propagate elsewhere, at least without a careful examination of the
various issues involved.

     The principle issue is that DOMAINS.TXT simulates domain-type
functionality with store-and-forward type of mailing.  Internet would
prefer that store-and-forward mailing didn't exist; while there are
features in SMTP and RFC 822 for it these features are made useless
due to the requirement that all host addresses must be valid Internet

     Another problem is that DOMAINS.TXT (along with the rest of the
TOPS-20 mailsystem) assumes a heuristic approach to the support of
domains.  I believe now that this is not the correct approach to take.
Heuristics have this way of being different between different
implementations at different sites, or even between different software
at the same site.  I now believe that a modified "host table" approach
is preferable, where instead of consulting a host table the software
on each site consults its local cache; failing that it goes to a name
server.  In both cases the entire domain string is treated as a single
atom by the host.
Date:      31 Mar 1984 14:12:26 PST
From:      [email protected]
To:        [email protected]
Cc:        [email protected], [email protected], [email protected], [email protected], [email protected]
Subject:   Re: DOMAINS.TXT creation
In response to your message sent  Sat 31 Mar 84 04:30:34-PST


Mark Crispin has done and is doing a great job of providing programs to
support applications in the Internet environment on TOPS20.  Mark's
User-Telnet "TN" is widely used as is his suite of mail programs.

Mark found himself supporting mail (and other) communications on TOPS20
in a fairly complex environment with several local networks and different
protocol families.  The Internet protocols did not at the time give any
guidance on how to handle the situation.  Mark invented a way to make
things work.  

The ideas about domains were just coming into being at that time and Mark
used the term to identify some of the entities in his scheme.

Somehow the general development of the domains idea for the Internet as a 
whole did not correspond exactly to what Mark did.  The Internet 
purposes, rules, and criteria for creating a domain turn out to be
somewhat different that those Mark used.

So the things that are "domains" in the mail programs in TOPS20s running
Mark's programs might not be appropriate domains in the Internet.