RFC 208 UNKNOWN ADDRESSING · DIRECTORY · SITES

Address tables

Network address directory for ARPANET sites

On rfc-editor.org ↗
PUBLISHED
August 1971
AUTHORS
A.M. McKenzie
STREAM
Legacy
CONNECTED SITES
15
SCHEDULED SITES
10+
ADDRESS FORMAT
8 bits (host 2 bits, IMP 6 bits)
DOI
10.17487/RFC0208

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                        A. McKenzie
Request for Comments: 208                        Bolt Beranek and Newman
NIC: 7181                                                  9 August 1971
Categories: B.l, C.2
Updates: none
Obsoletes: none


                             ADDRESS TABLES

   Attached is a copy of a revision to Appendix A of BBN Report No.
   1822; the revised version of the Appendix is our first attempt to
   make the list of sites attached to the ARPA Network prospective
   rather than retrospective.  We are adopting this approach because of
   the large number of sites scheduled for attachment in the near
   future, and because many Hosts apparently require a site's address to
   be in some local table before their NCPs will permit communication
   with the site.  Therefore, we urge such Hosts to add the new sites to
   their lists of addresses as soon as possible.  Also, please note the
   address change which will be made at BBN on exactly September first.

   Incidentally, it seems to us that it is irrational for an NCP to
   discard otherwise valid messages, simply because the sender's address
   doesn't appear in a local table.  Similarly, it seems almost as
   irrational for an NCP to prevent a local user from trying to
   communicate with a remote site, the address of which is known to the
   user but not stored in the NCP's tables.

Report No. 1822                             Bolt Beranek and Newman Inc.

APPENDIX A

IMP AND HOST SITE IDENTIFICATION

   Bit 9-16 of the leader of most Host-to-IMP or IMP-to-Host messages
   define a network address related to the message (these bits are not
   meaningful for message types 1, 2, and 4).  In a Host-to-IMP message
   the network address identifies a particular Host to which the message
   should be delivered.  In an IMP-to-Host message the network address
   identifies the Host from which the message originated.

   A network address consists of six bits (bits 11-16 of the leader)
   which specify an IMP number, preceded by two bits (bits 9-10 of the
   leader) which specify the Host number of a particular Host connected
   to that IMP.  The table below gives the decimal values of IMP number,
   Host number, and network address for each Host currently connected to
   the ARPA Network or scheduled for connection in the near future.
   Scheduled installation dates are also shown for Hosts not currently
   connected; these dates, however, are subject to change without
   notice.

    IMP      SITE     HOST                    NETWORK    SCHEDULED
   NUMBER    NAME    NUMBER       HOST        ADDRESS   INSTALLATION
   ------    ----    ------       ----        -------   ------------
     1       UCLA      0       SIGMA-7           1
                       1       IBM 360/91       65
     2       SRI       0       PDP-10 (NIC)      2
                       1       PDP-10 (Al)      66
     3       UCSB      0       IBM 360/75        3
     4       UTAH      0       PDP-lO            4
     5       BBN       0       DDP-516           5  )   See Note 1
                       1       PDP-10 (A)       69  )
                       2       PDP-1O (B)      133

   Note 1: Prior to September 1, 1971 the BBN PDP-1O (A) will be Host
   number 0 (network address 5) and the BBN DDP-516 will be Host number
   1 (network address 69).  The address change is to be made during the
   day on 9/1/71.

 IMP       SITE       HOST                      NETWORK     SCHEDULE
NUMBER     NAME      NUMBER      HOST           ADDRESS   INSTALLATION
------     ----      ------      ----           -------   ------------
  6        MIT          0       Honeywell 645        6
                        1       PDP-10              70
  7        RAND         O       360/65               7
                        1       PDP-1O              71
  8        SDC          O       IBM 360/75           8
  9        HARVARD      O       PDP-1O               9
                        1       PDP-1               73
                        2       PDP-11             137
 10        LINCOLN      O       IBM 360/67          10
                        1       TX2                 74
 11        STANFORD     O       PDP-1O              11
 12        ILLINOIS     O       PDP-11              12
 13        CASE         O       PDP-1O              13
 14        CARNEGIE     O       PDP-1O              14
 15        PAOLI        O       B6500               15
 16        NASA/AMES    O       IBM 360/67          16      8/3/71
                        2       TIP                144
 17        MITRE        2       TIP                145      8/31/71
 18        RADC         O       H 635/645           18      10/5/71
                        2       TIP                146
 19        NBS          O       PDP-11              19      11/2/71
 20        ETAC         2       TIP                148      11/30/71
 21        TINKER       O       418 III             21      1/4/71
 22        McCLELLAN    O       418 III             22      2/1/72
 23        USC          0       IBM 360/44          23      2/29/72
                        2       TIP                151
 24        GWC          2       TIP                152      3/14/72
 25        NCAR         O       CDC 7600            25      3/28/72
                        2       TIP                153
 30        BBN/TIP      2       TIP                158

AI ELI5

On this page
PROBLEMMany ARPANET hosts required local address tables before accepting messages from unknown senders. As the network grew and new sites joined regularly, these tables became outdated and restricted communication.
MECHANISMRFC 208 publishes the address assignments for all connected and near-future sites, organized by IMP number, host number, and network address. It urges hosts to update their tables proactively and argues against rejecting valid messages based on missing address entries.
EARLY DIRECTORYThis directory became one of the first ARPANET site lists. Later, DNS and centralized registries replaced local address tables.

§1Address Assignment and Tables

RFC 208 publishes the first comprehensive ARPANET host address directory. A network address in the ARPA Network is encoded in the Host-to-IMP message leader: bits 9-10 specify a host number (0-3) attached to an IMP, and bits 11-16 specify the IMP number (1-31). Together they form an 8-bit network address that identifies each host.

BBN recommended treating this directory as prospective rather than retrospective: it includes sites scheduled for imminent connection, not just those currently online. This allows hosts to add new sites to their local tables immediately, reducing delays when a new site comes online.

Each computer on the ARPANET gets a number made of two parts: which machine it is plugged into (IMP number) and which port on that machine (host number). The note lists all of them.

§2The Site Directory

RFC 208 tabulates the IMP numbers, host numbers, network addresses, and scheduled installation dates. At publication in August 1971, fifteen sites are connected: UCLA (IMP 1), SRI (2), UCSB (3), Utah (4), BBN (5), MIT (6), RAND (7), SDC (8), Harvard (9), Lincoln (10), Stanford (11), Illinois (12), CASE (13), Carnegie-Mellon (14), and Burroughs/Illiac (15). Additional sites from NASA/Ames through BBN/TIP are scheduled through March 1972.

The RFC also notes a critical address change at BBN: prior to September 1, 1971, the PDP-10 (A) will be Host 0; after that date it becomes Host 1, and the DDP-516 moves from Host 1 to Host 0.

Fifteen computers are on the net in August 1971. Ten more are about to join. Every few weeks, a new one plugs in.

§3Argument Against Address Filtering

RFC 208 argues that it is irrational for an NCP (Network Control Program) to discard valid messages simply because the sender's address does not appear in the local table. It is equally irrational to prevent a local user from attempting communication with a remote site whose address is known to the user but missing from the NCP's tables.

This critique foreshadows the later shift toward more open network routing and dynamic discovery, rather than requiring prior knowledge of all possible peers.

The note argues: do not reject mail from addresses not in your table. Let people talk even if the other person is new.

§4References

[BBN Report 1822]IMP-Host interface specification (Appendix A on site identification)