The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1982)
DOCUMENT: TCP-IP Distribution List for March 1982 (1 messages, 6203 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1982/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1982
From:      TCP-IP at BRL
To:        TCP-IP at BRL
Subject:   TCP-IP Digest, Vol 1 #17
TCP/IP Digest            Monday, 8 March 1982      Volume 1 : Issue 17

Today's Topics:
          Changes in IP since 1981 -- IP/TCP Document Editions
                NTIS Document Number for TCP/IP Documents
                  TOPS-20AN Birds of a Feather Session?
     TCP/IP for CYBER Status Report -- Ford Aerospace Status Report
    TELNET without TCP, for Speed? -- Need InterNet Name Server in C
     Xerox NS Protocol Query -- Need TCP/IP and Drivers for VAX/VMS
                          Suggestions for MCNC
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From: POSTEL at USC-ISIF
Subject: re: Addressing Questions in IP
To:   ODonnell at YALE
cc:   Postel at ISIF, TCP-IP at BRL

In answer your questions about addressing:

I think the major conceptual change from the January 1980 editions to 
the September 1981 editions is in the area of addressing.  (There are 
other changes I will describe in another message.)  The significant 
change is to treat the 32-bit address as having three formats or 
classes.

   Class A Address

      The first type of address has a 7-bit network number and a 24-bit 
      local address.

       1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   NETWORK   |                Local Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Class B Address

      The second type of address has a 14-bit network number and a 
      16-bit local address.

       1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 0|           NETWORK         |          Local Address        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Class C Address

      The third type of address has a 21-bit network number and a 8-bit 
      local address.

       1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 0|                    NETWORK              | Local Address |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The local address carries information to address a host in the network 
identified by the network number.

The assignment of network numbers is managed by a central authority 
(right now it is me, eventually it will be the NIC).  And, for certain 
networks the mapping of addresses in that networks context to Internet 
addresses will also be managed centrally (for example, Telenet to 
Internet).

The DOD Internet gateway procedures do use the network number as the 
fundamental piece of information to make the routing decision.  I don't 
think that DOD Internet Gateways have any more overhead in making the 
routing decision than Xerox NS Internet Gateways do, and i suspect that 
DOD gatways have less overhead.

Please get the latest editions of the specifications:  RFCs 790 through 
796.  These are in public access files in the Network Information Center
online library.  You can obtain copies via FTP.  Use the FTP username 
ANONYMOUS and password GUEST.  The pathnames for the files are of the 
form:

   <NETINFO>RFC790.TXT

--jon.

------------------------------

From: POSTEL at USC-ISIF
Subject: IP/TCP Document Editions
To:   ODonnell at YALE
cc:   postel at ISIF, tcp-ip at BRL

   There are two widely distributed editions of the documents describing
   the Internet Protocol (or IP) and Transmission Control Protocol (or 
   TCP), the DOD standard protocols for internetworking.  I would like 
   to clarify the status of these two editions, and note some of the 
   technical differences in the specifications.

   The first set of documents is dated January 1980 and carry the 
   reference numbers RFC-760, IEN-128, NTIS-ADA079730, and RFC-761, 
   IEN-129, NTIS-ADA082609, and these appeared in Computer Communication
   Review, Special Interest Group on Data Communication, ACM, V.10, N.4,
   October 1980.

   The second set of documents is dated September 1981 and carry the 
   reference numbers RFC-791, RFC-792, and RFC-792, (NTIS number applied
   for).

   Based on the first set of documents these prococols were ratified as 
   DOD standards by Gerald P. Dinneen (Assistant Secretary of Defense 
   for Communications, Command, Control and Intelligence) in April 1980 
   [see IEN-152].

   This set in motion a study effort managed by DCA to identify and 
   incorportate into the specifications additional capabilities 
   important in the military environment.

   Based on the results of the DCA study effort and other protocol 
   design improvements the second set of documents was produced.  These 
   September 1981 documents now are the current specification of the IP 
   and TCP for use in the DARPA research community and are being 
   considered for ratification as the DOD standard protocols for 
   internetworking to supersede the January 1980 edition.

   The differences between the two editions are at the overall 
   conceptual level quite minor, and the general principles of 
   operations of the protocols are quite similar.

   There are specific differences however.  In the IP, the interpretaion
   of the Internet Address is changed, the Type Of Service is slightly 
   changed, the security provisions are substantially different, and 
   there are now no header fields that change their length in 
   transmission or processing.  In the TCP, the "Rubber" End of Letter 
   is removed and replaced with a "Push" function.

   Changes in the IP specification:

      Addresses

         The Internet Address was formerly a 32-bit field rigidly 
         divided into a 8-bit Network number and a 24-bit address within
         network part. There were a maximum of 256 networks.  Now, while
         the field is still 32-bits, the division is more flexible.  Now
         there are possibilities for 128 class A networks (with 24-bit 
         address within network parts), 2^14 class B networks (with 
         16-bit address within network parts), and 2^21 class C networks
         (with 8-bit address within network parts).

      Type Of Service

         The type of service is changed to identify a specific use of 
         each of the 8 possible precedence values.  The remainder of the
         type of service is completely redefined in terms of delay, 
         throughput, and reliability.

      Security

         The security option is completely redefined to conform to 
         current military requiments.

      Variable Length Fields

         In the January 1980 edition several optional fields were 
         allowed to grow or shrink during processing in the gateways.  
         In the September 1981 edition this has been eliminated.  Now, 
         once the length for one of these option fields is set, it will 
         remain the same length for the life of that datagram.

      Option Type Codes

         The option type codes now include a bit that indicates if the 
         option is to be copied on fragmentation.

      Errors

         The Error option has been eliminated.  It is replaced by the 
         use of an auxilary protocol called Internet Control Message 
         Protocol (or ICMP) as part of the inplemetation of the Internet
         Protocol Module.  ICMP includes facilities for the notification
         of errors, and the exchange of control information between 
         Internet Protocol Modules.

   Changes in the TCP specification:

      End Of Letter

         The end of letter function was replaced by a push function.  In
         the January 1980 edition, the EOL was "rubber" in that it was 
         tied to a buffer size, and the end of letter consumed the 
         remainder of the buffer and that amount of the transmission 
         sequence numbers.  Also there was some confusion of the end 
         user to end user significance of the end of letter -- could it 
         act as a user level record marker?

         In the September 1981 edition, there is only a push function.  
         This push function is not explicitly involved in buffer space 
         allocation nor does it consume sequence numbers.  It does mean 
         that any data should be delivered as promptly as possible even 
         if buffers are not most efficiently utilized.  The push can not
         act as a user level record marker.

         In conjunction with this change the Buffer Size option was 
         eliminated.

      Closing States

         Some additions were made to the connection closing procedure to
         properly account for all the possible sequence of actions and 
         to be sure the timeout on the connection record is used when 
         necessary.

      Small Corrections to Handling ACKs and RSTs

         Some small corrections were made to the processing of ACKs and 
         RSTs (mainly in the pre established states).

      Comment on Retransmission Policy

         A small discussion was added to suggest a way of determining 
         and maintaining a dynamic model of the proper retransmission 
         timeout.

      Comment on Window Policy

         A small discussion was added to suggest a way overcoming the 
         tendency for the window increments and the transmitted data 
         segments to become smaller and smaller.

      Comment on Quite Time

         A discussion was added on the reasons the TCP should not 
         immediately begin to transmit segments on recovery from a 
         system crash.

      Maximum Segment Size

         An option was added to all the specification of the maximum 
         segment size that a TCP module can accept.

   --jon.

------------------------------

From: POSTEL at USC-ISIF
Subject: IP/TCP Specifications in NTIS
To:   TCP-IP at BRL
cc:   Postel at ISIF

The current specifications of IP/TCP are now available from NTIS.
The collection of RFCs 790 through 796 is on file as one document
at NTIS under the title
"Internet and Transmission Control Protocol Specifications" 
The NTIS number is   AD A111091.

--jon.

------------------------------

From: Kevin Paetzold <PAETZOLD at DEC-MARLBORO>
To: tcp-ip at BRL
DTN: 231-7430
Mail-stop: MR1-2/L10
Telephone: 617-467-7430
Subject: ARPANET liason meeting (east coast march 26 at BBN)

	Would you forward this to the TCP/IP digest.  Arnold Miller
and I will be attending the ARPANET liason meeting to be held on
March 26 at BBN.  We would like to schedule a "TOPS-20AN Birds of a 
Feather" type meeting for any liasons from TOPS-20 sites.  We will
discuss what DEC plans on doing to support TCP/IP under TOPS-20.
Exact time and place for this meeting have not yet been determined.
More info will follow.  Interested parties may send mail to us.
PAETZOLD@DEC-MARLBORO and MILLER@DEC-MARLBORO.

Kevin Paetzold
Digital Equipment Corporation

------------------------------

From:      Crimmins at BRL-BMD
Subject:   TCP/IP for CYBER

	I spoke with Tim Fallon of Tektronix about the status of
 the Tektronix version of TCP/IP. Tim said a decision should be
 made by 1 Apr 82, he sounded like Tektronix will release it but
 the details where not yet set.
     
					TomC

------------------------------

From: Sherman at SRI-KL
Subject: FACC interneting
To:   tcp-ip at BRL

Hi Digest,
     We at Ford Aerospace and Communications have been developing
an internal network based on IP/TCP. We currently have
a collection of Fuzzballss (DCNet via D. Mills) operating on a 
LAN. This is in turn connected via phone lines to a VAX
running Berkely BSD 4.1 UNIX with UNET ver 1.6 from 3Com.
     We have developed a number of application programs (ftp and
smtp) compatible with the lattest internet specifications.
We also plan to include some other PDP11 UNIX System III players.
     Regards,
     Dick Sherman

------------------------------

Subject: TELNET protocols...
From:  William "Chops" Westfield <BillW@SRI-KL>
To: tcp-ip at BRL

It seems to me that by the time you put Telnet on top of TCP and
IP, the telnet connection is probably more reliable than the TTY-host
connection, at the expense of a lot of CPU overhead.  Now, as more
and more of the terminals connected to a host come in over a network
rather than through normal TTY ports, this could become a problem.

Has anyone considered putting some kind of modified Telnet protocol
directly on top of IP ?  FTP and MAIL and other things that need
the reliability can use the normal Telnet [TCP] protocol, but it would
be nice if tying user terminals to a host over a net (especially
a local net, where transmission is relatively reliable by itself),
were computationally cheaper...

Bill Westfield
Networks Development, SRI

------------------------------

From: ARPAVAX.sam at Berkeley
To: tcp-ip at brl
Subject: Internet Name Server

Does anyone have a C implementation of the Internet Name Server
they'd be willing to share?

	Sam Leffler
	sam at berkeley

------------------------------

From: Roy Marantz <MARANTZ at RUTGERS>
Subject: Xerox protocol query
To: tcp-ip at BRL

Can someone give me pointer(s) to where I can get information on the
newly release protocol (NS?) from Xerox?  I've heard of the announcement,
but haven't seen it anywhere.  Thanks.

Roy

------------------------------

From: Steve Berlin <BERLIN at MIT-XX>
Subject: TCP/IP and drivers for VMS
To: tcp-ip at BRL, info-vax at SANDIA

We are acquiring about two dozen VAX-750's during the next few months, and
are currently deciding what network hardware and software we will use.  It
looks like we will have both LNI and 3Com Ethernet hardware, and possibly
Chaosnet as well.  The transport protocol will probably be TCP/IP.  I would
like pointers to any software, particularly drivers and TCP/IP
implementations, that is available for either UNIX or VMS.  We have TCP/IP
for UNIX from Gurwitz @ BBN.  Does anybody have further news of the TEKLABS
TCP/IP for VMS?  Thanks for your help.

------------------------------

From: mo at LBL-UNIX (Mike O'Dell [system])
To: BERLIN at MIT-XX
cc: tcp-ip at BRL, info-vax at SANDIA
Subject: Re: TCP/IP and drivers for VMS

Try Digital Technology Inc. in Urbana Illinois.
	-Mike

------------------------------

[ The following letters contain suggestions for the MicroElectronics
  Center of North Carolina, which requested advice in the last digest.  -M ]

From: Chris Ryland <Ryland at SRI-KL>
To:   TCP-IP at BRL
Subject: TCP-IP Digest, Vol 1 #16, request from Steven M. Bellovin

With all that hardware running Unix, I'd run Chaosnet, which is about
the most proven local network available today.  You don't clearly need
any internetwork support, which is why I recommend Chaosnet.

------------------------------

Subject: Re:   TCP-IP Digest, Vol 1 #16
From: CERF at USC-ISI
To: TCP-IP at BRL

For Steve Bellovin:

I would suggest you use the Berkeley Vax/TCP/IP protocol
base, and get 3COM UNET for the 11/70 and other 11's, also
for XENIX. The 11/23's could run the DCNET software from COMSAT
(Dave Mills). The MVS could run the UCLA TCP/IP software
package (Bob Braden - Braden@ISIA).   The CSNET system is
a good model for some of what you want to do.  VMS TCP/IP
can be had from DTI Inc sometime in April this year for the
NCSU systems.

As to the actual networks to connect all this - not so clear,
but it sounds as if you'll need some gateways to connect
local nets to public or private long-haul nets.

Vint Cerf

END OF TCP-IP DIGEST
********************

END OF DOCUMENT