Historical Hacking Philes: ARPANET Information Brochure (1985)




Stephen C. Dennett
Elizabeth J. Feinler
Francine Perillo

Additional copies of this document may be obtained from the DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Room EJ291, Menlo Park, CA 94025, or from the Defense Technical Information Center (DTIC), Cameron Station, Alexandria, VA 22314.

UNIX is a registered trademark of AT&T Bell Laboratories. TELENET is a registered trademark of GTE. TYMNET is a registered trademark of TYMNET Inc., a subsidiary of McDonnell Douglas Corporation.

ARPANET Information Brochure. Printed and bound in the United States of America. Published by the DDN Network Information Center, SRI International, Menlo Park, CA 94025.


Date: December 1985


ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . III

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

SECTION 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . 1
1.1. How To Use This Document . . . . . . . . . . . . . . 1

2.1. What is the ARPANET? . . . . . . . . . . . . . . . . 3
2.2. Management of the ARPANET . . . . . . . . . . . . . 3
2.2.1. DARPA/IPTO . . . . . . . . . . . . . . . . . . . . 3
2.2.2. DDN PMO Responsibilities . . . . . . . . . . . . . 3
2.2.3. IAB Responsibilities . . . . . . . . . . . . . . . 3
2.3. ARPANET Access and Use Policies . . . . . . . . . . 4
2.3.1. Host Access Controls . . . . . . . . . . . . . . . 4
2.3.2. TAC Access Controls . . . . . . . . . . . . . . . 4

SECTION 3. SUBSCRIBER ACCESS PROCEDURES . . . . . . . . . . . . . . 5
3.1. Process Overview . . . . . . . . . . . . . . . . . . 5
3.1.1. Feeder TSRs . . . . . . . . . . . . . . . . . . . 6
3.2. Backbone Hardware Requirements . . . . . . . . . . . 6
3.2.1. Types of Service . . . . . . . . . . . . . . . . . 6
3.2.2. Equipment Procurement and Costs . . . . . . . . . 6
3.2.3. PSN Port Assignment . . . . . . . . . . . . . . . 7
3.3. TAC Connection . . . . . . . . . . . . . . . . . . . 7
3.4. Registration Procedures . . . . . . . . . . . . . . 7
3.4.1. Host Registration . . . . . . . . . . . . . . . . 7
3.4.2. Host Addresses and Domains . . . . . . . . . . . . 7
3.4.3. LAN and Gateway Registration . . . . . . . . . . . 7
3.4.4. User Registration . . . . . . . . . . . . . . . . 7 NIC Registration Template . . . . . . . . . . . 7 NIC REGISTER Program . . . . . . . . . . . . . . 8
3.4.5. ARPANET TAC Access Registration . . . . . . . . . 8

SECTION 4. ARPANET PROTOCOLS . . . . . . . . . . . . . . . . . . . 9
4.1. DDN Protocol Handbook . . . . . . . . . . . . . . . 9
4.2. TCP/IP Implementations and Vendors Guide . . . . . . 9
4.3. RFCs . . . . . . . . . . . . . . . . . . . . . . . . 9

5.1. Subscriber Software and Hardware Modification
Requests 11
5.2. ARPANET Software/Node Modification Procedures . . . 11

SECTION 6. NETWORK INFORMATION SERVICES . . . . . . . . . . . . . . 13
6.1. DDN Network Information Center . . . . . . . . . . . 13
6.1.1. User Assistance Service . . . . . . . . . . . . . 13
6.1.2. NIC Contacts . . . . . . . . . . . . . . . . . . . 14
6.1.3. Online Servers . . . . . . . . . . . . . . . . . . 14 TACNEWS . . . . . . . . . . . . . . . . . . . . 14 WHOIS/NICNAME . . . . . . . . . . . . . . . . . 14 Host Name Server . . . . . . . . . . . . . . . . 14
6.1.4. Documents . . . . . . . . . . . . . . . . . . . . 14
6.1.5. Online Files . . . . . . . . . . . . . . . . . . . 15
6.2. ARPANET Network Monitoring Center . . . . . . . . . 15
6.2.1. AMC Contacts . . . . . . . . . . . . . . . . . . . 15
6.3. Complaint Center/Unsatisfactory Service Reports . . 15

SECTION 7. KEY CONTACTS . . . . . . . . . . . . . . . . . . . . . . 17
7.1. DDN PMO Contacts . . . . . . . . . . . . . . . . . . 17
7.2. DARPA Contacts . . . . . . . . . . . . . . . . . . . 17
7.3. Contacts for Specific Services . . . . . . . . . . . 17

SECTION 8. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Cited References . . . . . . . . . . . . . . . . . . 19
8.2. Additional References . . . . . . . . . . . . . . . 19

SECTION 9. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . 21

APPENDIX. SITE PERSONNEL DUTIES . . . . . . . . . . . . . . . . . 23

List of Figures

Figure 2-1: Hardware and Configuration of the DDN 3
Figure 2-2: Management of the ARPANET 3
Figure 3-1: ARPANET New Subscriber Request Flow 5
Figure 3-2: Sample Feeder TSR Template 6
Figure 3-3: Host Data 7
Figure 3-4: Host Administrator Data 7
Figure 3-5: Sample User Registration Template 7
Figure 5-1: Modification Request Procedure 11



The ARPANET Information Brochure was prepared by the DDN Network Information Center (NIC) for the Defense Advanced Research Projects Agency and the Defense Data Network Program Management Office of the Defense Communications Agency under contract number DCA-200-83-C-0025.

The NIC wishes to acknowledge the valuable assistance of Lt. Col. Bob E. Baker of the Defense Advanced Research Projects Agency, Andrew Hogan of the Defense Data Network Program Management Office, and Alan Hill of BBN Communications Corporation in the preparation of this document.



The ARPANET is an unclassified, packet-switched data network originally built by the Defense Advanced Research Projects Agency (DARPA) and used for Department of Defense computer science and networking research. It is now one of the subnetworks of the Defense Data Network (DDN) and, as such, is managed by the Defense Data Network Program Management Office (DDN PMO). Policy for the ARPANET is established by DARPA and they also decide who may become subscribers. Subscribers are required to follow certain technical and administrative procedures to connect host computers or other equipment to the DDN. This document describes these procedures as they apply to the ARPANET, provides background and technical information on the ARPANET, and suggests sources of further information on protocol implementations and interface equipment.



The Defense Advanced Research Projects Agency (DARPA) may require its contractors or associated researchers to become ARPANET “subscribers” (sites which have host computers or other equipment connected to the network). In such cases DARPA requests authorization from the Defense Data Network Program Management Office (DDN PMO) to add the required equipment to the network.

This document describes the steps necessary for potential subscribers to attach host computers or other equipment to the ARPANET. Administrative and technical procedures are included. References to documents and services, which will be helpful during the process of connecting equipment to the network, are also included and are designated by the number of the reference in brackets, e.g. [1].


1.1 How To Use This Document

Section 1, the Introduction, explains how this document is organized.

Section 2 provides background on the ARPANET, describes the current management structure, and states the criteria for becoming a subscriber.

Section 3 presents the administrative and technical procedures necessary to bring a host onto the ARPANET. Different types of network connections and associated costs are described.

Section 4 discusses the protocols used on the ARPANET and the DDN, and tells how protocol implementations and documentation may be obtained.

Section 5 describes the administrative procedures required for requesting modifications of network software or hardware.

Sections 6 and 7 describe the services and personnel available to help with the process of connecting equipment to the ARPANET and with using the network.

Section 8, References, contains citations and sources for publications which provide further useful information. This section explains how to obtain both hardcopy and online documents.

Finally, the Appendix contains important information on the duties assigned to local network representatives. Comments or suggestions for improvements to the document are welcome. Send these by U.S. mail using the Comments Form at the end of the document or through network mail to: SUGGESTIONS@SRI-NIC.ARPA.



This section presents background on how the ARPANET evolved into what it is today, and how it is currently managed.


2.1 What is the ARPANET?

The ARPANET began as an experimental packet-switched host-to-host network in late 1969. It was funded through a research and development program sponsored by DARPA. The goal of the program was to advance the state-of-the-art in computer networking. The resultant network successfully provided efficient communications between heterogeneous computers, allowing convenient sharing of hardware, software, and data resources among a varied community of geographically-dispersed users.

In 1982 the DDN was created. The DDN uses ARPANET technology to link existing and planned Department of Defense (DoD) networks. It is composed of several operational, resource sharing, host-to-host networks which are linked by controlled gateways, and which serve DoD facilities and non-DoD research centers in the United States, Pacific, and European areas. All of the networks that make up the DDN share the same “backbone” of node computers. (See Figure 2-1 for a pictorial overview of the network hardware and configuration). Node computers are interconnected through a set of communications protocols referred to as the DoD Internet Protocol Suite.

In 1983, the existing ARPANET was administratively divided into two unclassified networks, ARPANET and MILNET, to meet the growing need for an unclassified operational military network as well as the need for a research and development network. The physical split into separate networks was completed in September 1984. Each network now has its own backbone, and is interconnected through controlled gateways to the other. The ARPANET serves primarily as an experimental research and development network, while the MILNET functions as an operational military network for non-classified traffic. Communication and resource sharing between them continue, but are subject to administrative restrictions.


2.2 Management of the ARPANET

The DDN, including ARPANET, is operated for the DoD by the Defense Communications Agency DDN PMO. For an overview of the management structure for ARPANET, see Figure 2-2.





DARPA’s Information Processing Techniques Office (IPTO) is dedicated to developing advanced information processing and computer communications technologies for critical military and national security applications. The building of the ARPANET and development of its protocols was an IPTO program, which has evolved into what is now known as the Internet Research Program.

Through IPTO, DARPA sets policy for, and manages use of, the ARPANET. This is done within broad guidelines established for all DDN networks by the DDN PMO. It also funds the ARPANET, and funds research carried out on the ARPANET. Since there have been recent changes, it is important to reiterate that the DDN PMO operates and manages the ARPANET, including the node software and hardware, while DARPA pays the backbone operating costs, sets policy for the ARPANET, and approves access for DARPA-sponsored subscribers.


2.2.2 DDN PMO Responsibilities

The DDN PMO is responsible for overall management, operations, and policy guidelines for the entire DDN. It assists new subscribers in connecting hosts and related equipment to the DDN, and manages the ARPANET on behalf of DARPA. The DDN PMO provides many services to network users and potential network subscribers, including:

  • – Keeping the network up and running
  • – Providing users with assistance
  • – Planning for growth
  • – Providing configuration management and control
  • – Assisting with protocol implementation and testing
  • – Advising subscribers on the selection of interface equipment and
  • software
  • – Managing access control and security for the network backbone
  • – Designating local host and node representatives
  • – Arranging for all equipment required to establish a network
  • connection
  • – Providing technical management of contracts for services,
  • equipment, and software obtained from outside corporations and
  • vendors.

The Data Operations Division, Code B650, of the DDN PMO manages all DDN networks, including the ARPANET. For each DDN network, a PMO staff member has been designated as the primary “point of contact” (POC). All operational questions should be referred to this POC. (See Section 7 for the phone number and mailbox of the ARPANET POC). The Data Operations Division is also responsible for coordinating operational matters within the DDN PMO itself, as well as with other branches and divisions of the DCA and with DARPA.


2.2.3 IAB Responsibilities

The DARPA Internet Research Program is directed by DARPA IPTO with the assistance of an Internet Advisory Board (IAB) and a set of IPTO-appointed Task Forces (technical working committees). The IAB consists of the chairmen of the Task Forces, the DARPA Program Manager, the Chairman of the IAB (the Internet Architect), the Deputy Chairman, and the Secretary of the IAB.

The IAB guides and reviews the work of the Task Forces, and ensures proper cross communication among them. The IAB may from time to time create new, or disband existing, Task Forces.

The Task Forces are expected to generate and develop new ideas, to monitor the technical work of the Internet program, and to recommend additional research activity. The role of the Task Forces is seminal and advisory, and very important to the advancement of the research goals of the Internet program.

Members of each Task Force are chosen by its chairman, and they are expected to make a moderate commitment of time to the work of the Task Force. Most Task Forces also have mailing lists for persons interested in following the work of a given Task Force.

Current Task Forces and chairmen are:

Task Force Chairman Organization (See Glossary)

  • Applications Bob Thomas BBNCC Gateway Algorithms
  • and Data Structures Dave Mills M/A-COM Interoperability
  • and Autonomous Systems Robert Cole UCL
  • New End to End Services Bob Braden UCLA
  • Privacy Steve Kent BBNCC
  • Robustness and Survivability Jim Mathis SRI
  • Security Ray McFarland DOD
  • Tactical Internetting David Hartmann MITRE
  • Testing Ed Cain DCEC

IAB officers are:

  • Position Occupant Organization
  • Internet Architect Dave Clark MIT
  • Deputy Internet Architect Jon Postel ISI
  • DARPA Program Manager Dennis Perry DARPA
  • IAB Secretary Chris Perry MITRE

Phone numbers for IAB members are available through DARPA.


2.3 ARPANET Access and Use Policies

DARPA and the DDN PMO have set broad guidelines for ARPANET access and use, administered locally by volunteer site personnel called Host Administrators. Legitimate ARPANET users must be engaged in U.S. government business or research, or directly involved in providing operations or system support for government-owned or government-sponsored computer communications equipment. The network is not available for use by the general public, nor is it intended to compete with comparable commercial network services.

The purpose of the ARPANET is to provide a facility for advanced packet-switched communications technologies research and experimental communication support of government-sponsored university computer science research. Consequently, access to, and use of, ARPANET will not be authorized to support operational (as opposed to experimental) communication requirements. Such operational facilities are provided for DoD users by the DDN, and for others by public and private packet-switched networks (such as TYMNET or TELENET).

Users of ARPANET may only use the network to conduct the official business for which their access was authorized. They must not violate privacy or any other applicable laws, and must not use the network for private gain or for commercial purposes, such as advertising or recruiting. ARPANET users may connect to other DDN networks only when approved by the DDN PMO on a host-by-host basis.

Host site personnel are responsible for developing and enforcing specific policies to ensure that these guidelines are followed. (See the Appendix for a formal statement of site personnel responsibilities). The Host Administrator is given the authority to disallow access to the ARPANET by users who use the network irresponsibly or for unauthorized purposes. The DDN PMO assumes this authority only in an emergency, or if administration at the local level is not functioning.


2.3.1 Host Access Controls

Subscribers and sponsors are responsible for letting only authorized users have network privileges. All non-government users should be associated with a valid contract number, or have explicit permission to use the ARPANET. Additionally, host sites must maintain these controls:

  • – Procedures that allow only valid users to obtain accounts on government-owned computers or to obtain access to the ARPANET backbone from the host
  • – Login Name/Password so that only valid users can access the host
  • – Periodic Reviews of users so that persons who no longer need ARPANET access are denied such access and unused accounts are closed.

Any attempts to break into a system from the network should be reported by the Host Administrator to the DDN PMO and DARPA by telephone or U.S. mail.

When violations of the above policies are observed, DCA will notify the site personnel. If the problem is not corrected within a reasonable time, DCA may exercise the option of disconnecting the host or terminal from the network.


2.3.2 TAC Access Controls

A Terminal Access Controller (TAC) is a computer system attached directly to the DDN that lets a user at a terminal connect to hosts on the network without first going through a local host. (See Section 3.3 for a description of a TAC connection).

ARPANET users must be authorized for network TAC access by a DARPA-appointed network contact known as a “Responsible Person” (RP). An RP is a person in a position of authority within each organization authorized to use the ARPANET. The RP is responsible for ensuring that TAC access to the ARPANET is only allowed for those members of his organization with a valid requirement for such access. The RP, or his delegate, sees that TAC users are entered into the ARPANET TAC User Database (UDB) accessible through the network. The RP uses the UDB to generate a “USER ID” and an “ACCESS CODE” for each user.

The User Database is downloaded regularly to several “login hosts” throughout the ARPANET. These hosts verify authorized use at the time a user logs in to a TAC. When an ARPANET TAC user tries to open a connection to a host from a TAC, the TAC requests a USER ID and ACCESS CODE, then interacts with a login host to validate the user. If the login host reports that the USER ID/ACCESS CODE is invalid, the TAC prints an error message and refuses to open a connection. Access is thus restricted to users whose names have been entered into the user database.

MILNET, the DoD’s operational military network which shares the DDN backbone with ARPANET, also contains TACs and has a system of registering MILNET TAC users. Although these registration systems serve the same purpose, they are different in operation, and are physically and administratively completely independent from each other. A user authorized for access through both MILNET and ARPANET TACs must register twice, once in each system. Note that the login procedure itself is identical whether the user logs in from ARPANET or MILNET. Only the user registration procedures are different.

Lack of local ARPANET TAC resources is not considered sufficient reason to provide ARPANET users with MILNET TAC access and vice versa. MILNET TACs are provided to assist authorized users in carrying out DDN operational tasks. Contact the DARPA POC (see Section 7.2) if you are an authorized ARPANET user and there is no ARPANET TAC available in your area.



This section describes how a potential ARPANET subscriber can apply for access to the network. It compares the different types of connections available, and describes how terminals can access hosts through the network TACS.

NOTE: The entire process from application to completion may require over a year if installation of phone lines or node equipment is required. It is important to plan ahead and let DARPA and the DDN PMO know what your anticipated needs are.

The process of becoming a subscriber involves several steps. It must first be determined that the potential subscriber has a legitimate need to access the network and has authorization from DARPA to use the network. Paperwork must be submitted to authorize the DDN PMO to begin the process of ordering all equipment required to establish a network connection.

Site personnel must arrange to lease or purchase a host computer (if one is not already available), and to implement or procure implementations of network protocols that will run on it. They must also arrange for the installation and testing of site hardware. The sections that follow describe these procedures in greater detail.


3.1 Process Overview

All ARPANET host connections are managed by the Packet Switching Operations Branch, Code B652, of the DDN PMO. The procedures for getting a host connected to ARPANET are outlined below.

a. Contact Code B641 of the DDN PMO, who determines whether the requirement qualifies for ARPANET or MILNET connection.

b. Contact the ARPANET Coordinator in the Information Processing Techniques Office (IPTO) at DARPA, who will verify government sponsorship and will provide the required Feeder Telecommunications Service Request (TSR), Host Approved Form (HAF) and, when necessary, the Internet Protocol Network Number Request Form.

c. Submit the filled-in Telecommunications Service Request (TSR) forms to DARPA for approval and subsequent forwarding to Code B643 and Code B652 of the DDN PMO.

d. The TSR is issued by the DDN PMO. The requester receives a hardcopy confirmation via Mailgram, TELEX or AUTODIN message.

e. Requester also receives a Telecommunications Service Order (TSO) delivered via the same means.

f. The Installation Branch, Code B642, generates a Network Change Request (NCR) from host data provided by Code B652.

g. The NCR is approved by Code B652 of the PMO and becomes a Network Change Directive (NCD). Host data is added to the NIC host table, the ARPANET Monitoring Center (AMC) activates the host port, and the requester receives electronic mail confirmation of the NCD.

h. When the host is installed, the requester receives a completion report by the same means as the original TSR.

NOTE: The TSR and TSO indicate the assigned network address, and therefore, the network node through which service will be provided. Each node has a Node Site Coordinator (NSC) (See Appendix ), whom the host requester may wish to contact concerning cabling or other connection mechanisms between the host and node locations. If a new node must be installed at the site before hosts can be connected to the network, an NSC will have to be appointed, who should be prepared to assist DDN PMO field representatives with node equipment installation.



3.1.1 Feeder TSRs

The Feeder TSR provides information for assessing the applicant’s need for network access, and is a preliminary request for service leading to the issuance of a full TSR by the DDN PMO. To submit a Feeder TSR for ARPANET service, the template shown in Figure 3-2 must be completed.

The parts of the Feeder TSR are:

  • (1) TSR ITEM NUMBER – the number for each entry.
  • (2) INFORMATION – data provided by the applicant; on the sample template (Figure 3-2) a description is provided of the information required for each item.
  • (3) TYPE OF ACTION – indicates whether applicant must complete an item, contingent upon choice indicated in Item 103.

For example, if you are starting service, write “start” on line 103 in the information column. You must then fill in information for all lines where there is an “X” in the “START” column under “Type of Action”. If you have questions about the template, contact the ARPANET Coordinator at DARPA or the ARPANET POC at the DDN PMO.

(1) (2) (3)

— ———– —————————-

  • 103 TYPE OF ACTION (Start, Change, Discontinue, Amendment, Rehome)
  • 104 Fill in the words “LEASED EQUIPMENT/ SERVICE CONTRACT” if leased modems and maintenance is required to be provided by the government
  • 105 Fill in the word “DEDICATED” if ARPANET and “DDN” if MILNET
  • 106 State the requested service date by day, Greenwich Mean Time, Month, and Year. e.g. 141200Z JUL 84.
  • NOTE: A minimum of 150 days is required for circuits.
  • 111 Enter the data rate (2.4KB, 1.2KB, 4.8KB, 9.6KB, 50KB, 56KB, 100KB) of the requested service.
  • 116 Enter the words “NEW LEASE” if this is a new requirement, or enter the Commercial Communications Service Authorization Number (CSA) if this is an amendment, rehome, disconnect, or change to an existing requirement. If no circuit is required, omit this item.
  • 120A The end user location requiring ARPANET/MILNET Access (Geographical location, e.g. city, base, camp, post or station that is applicable)
  • 121A State of the end user location
  • 123A CPV
  • 124A The building number where the user’s terminal or host is located that will be connected to the ARPANET/MILNET
  • 125A The room number where the user’s terminal or host is located that will be connected to the ARPANET/MILNET
  • 126A The type of terminal or host equipment that will be connected.
  • 128A The user interface that will be connected up to the circuit (RS-232C, RS-449, Synchronous, Asynchronous, MIL-STD 188-114, Leased Modem)
  • 130A Provide the name, telephone number and office code or symbol of a primary and alternate person at the user’s terminal end that is familiar with the details and requirements of this request
  • 131A Provide the complete mailing address of the primary person identified in
  • 130A, including the agency, street address, building number, city, state and zip code.
  • 353 Fill in “ARPANET” or “MILNET”
  • 354 If this requirement is for a terminal connection and not a host, enter the data link protocol (e.g. asynchronous)
  • 357 If this requirement is to connect a host, enter the software and hardware interface requirements (e.g. RS232/ V.35/MIL-188-114/Bell 303/cable only and HDH/X.25/DH/DH with ECU’s
  • 361 If this requirement is for a terminal connection and not a host, enter “ASCII”
  • 401 State the exact requirement of this request, e.g. The purpose of this request is to request leased modems and circuit between end points.
  • 407A If this request is to provide leased modems, state so here, and if the modem is to be a stand alone or rack mounted in a cabinet. If additional equipment is to be leased, state so (e.g. 1-ea 72 inch modem cabinet, 2-ea 25 ft RS-232 M/F connection cable). All equipment to be provided by the government should be listed here.
  • 409 The individual at the user site who  will accept service.
  • 417 If this requirement is to connect up  a host, please list the host name along with any narrative remarks which will help to clarify this requirement. e.g. statement that user is providing circuit and modems if that is the case, statement that no circuit is required due to it being a local connection if that is the case, desired/recommended PSN for connection. In all cases, the electronic mail address for the person shown in 130A should be indicated here.
  • 430 Estimated length of service requirement  (12, 24, 36, 48, or 72 months)
  • 431 “N” if ARPANET, “D” if MILNET
  • 437A YES OWM
  • 438A “NONE” if no leased equipment is required or “BOTH” if this request includes both circuit and associated leased equipment.
  • 501 Justification for the service being requested, e.g. To provide UCLA connection to the ARPANET for testing host interfaces.


Figure 3-2: Sample Feeder TSR Template

Submit the feeder TSR templates for ARPANET service to DARPA:
U.S. Mail Address

Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard, 7th Floor
Arlington, Virginia 22209


Phone: (202) 694-5921

Network Mailbox



3.2 Backbone Hardware Requirements


3.2.1 Types of Service

The network interface can be either full service (supporting all DDN protocols) or limited service. A full-service interface is recommended whenever possible, as it provides the most functionality for users.

Limited service may be provided by a terminal emulation interface, or an interface supported by vendor-specific protocols. Either type may be used temporarily while awaiting a full-service interface. Permanent installation of limited-service interfaces should be restricted to terminal emulation interfaces, and to systems where the cost of a full-service interface would be prohibitive.

For complete information on types of service available on the DDN, see the DDN Subscriber Interface Guide [1].


3.2.2 Equipment Procurement and Costs

Costs for connection to the ARPANET are not fixed, but are arranged on an individual basis. Generally, DARPA pays backbone costs and the contractor pays all other costs (including Error Correction Units and interface units, when required). For detailed information, contact the ARPANET POC (see Section 7.2).


3.2.3 PSN Port Assignment

The initial Packet Switch Node (PSN, formerly called Interface Message Processor or IMP) port assignment is sent to the subscriber as part of the TSR/TSO process (described in Section 3.1.1). Subscribers must not change PSN ports or switch equipment on PSN ports without approval through the TSR/TSO process.

Note that PSN port changes must have proper authorization and will not happen instantaneously. Also, if a host is changed to a different PSN port, its host address will change (see Section 3.4.1). Contact the ARPANET POC or the NIC for assistance in obtaining a PSN port change or if problems with host names or addresses arise.


3.3 TAC Connection

ARPANET users may access a network host via a TAC, which is a special terminal access node. TACs let a terminal connect directly to the network, i.e., without going through another host. Terminals may be either hard-wired to the TAC or connected by a dial-up modem. A user geographically remote from a given host can dial up a nearby TAC, log in, open a connection to the distant host, and work as if he were connected locally. Thus, the TAC lets the user reach his host through the network, rather than through a direct long distance telephone call to the host.

Current TAC locations and phone numbers are available from the NIC. If installation of a TAC appears to be necessary for your area or user population, contact the DARPA POC and describe the need for the installation of a TAC at the designated location. DARPA will evaluate the request and, if the request is warranted, will place an order for TAC installation with the DDN PMO.


3.4 Registration Procedures

The following sections discuss the administrative steps a potential subscriber should take to register a host, and the procedures required to register users once the host is connected to the net. Figure 3-1 gives an overview of the process.


3.4.1 Host Registration

Each host on the DDN is identified by a unique host name and host address. To register a host, information must be supplied to DCA Code B652, the Packet Switching Operations Branch, as shown in the following examples (Figures 3-3, 3-4). Send completed forms online or by U.S. mail to the ARPANET Coordinator at DARPA.

Host Data (Sample)

LOCATION: Bolt Beranek and Newman Inc.
1300 North 17th Street
Suite 400
Arlington, Virginia 22206

Figure 3-3: Host Data


Host Administrator Data (Sample)

NAME: Chipman, Steven G.
U.S. MAIL ADDRESS: Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, Massachusetts 02238
TELEPHONE: (617) 497-3505 (now 873-3505, May 89)
Figure 3-4: Host Administrator Data


3.4.2 Host Addresses and Domains

The host address contains four decimal numbers, each separated by a period. Each part represents one octet of a 32-bit address. The meaning of each octet depends upon which class of network it describes. There are three classes of networks (Class A, Class B, and Class C), based upon the network’s size and function.

On Class A networks, which are large, long-haul networks such as ARPANET and MILNET, the first octet indicates the network number. The second octet refers to the host port number on the PSN; the third octet is reserved, and is usually zero; and the last octet is the number of the PSN to which the host is connected.

For Class B networks, the first two octets indicate the network portion of the number; for Class C networks the first three octets are used to indicate the network number. For more information on address mappings, see RFC 796 [2].

The DDN Network Information Center maintains the official DoD Internet Host Table and is the network Hostmaster for names and addresses of hosts, networks, nodes and domains. Hosts should arrange to regularly update their local tables by retrieving all or part of the master table from the NIC Host Name Server. For information about the DoD Internet Host Table specification, see RFC 952 [3].

In the near future, all DARPA hosts will be required to either join an existing “domain” or to administer a domain of their own. Domains are administrative entities that provide decentralized host naming and addressing management. Their purpose is to distribute the task of naming and addressing.

Under the domain-naming scheme, information is stored in a distributed, hierarchical database. Responsibility for naming domains (or sub-nodes of the hierarchical naming tree) can then be delegated to different organizations, each with responsibility for maintaining host-related information for their domain. Information about hosts and domains is disseminated through the network via Name Servers. For more information on domains, see RFC 920 [4] and RFC 921 [5].

The domain system on ARPANET is experimental. The MILNET has not yet implemented the domain system. The NIC name server translates between the two systems and continues to provide a “flat” domainless host table for use by MILNET hosts while serving as registrar for domain names for the Internet.


3.4.3 LAN and Gateway Registration

Subscribers wishing to connect a local area network (LAN) or other non-DDN network to the ARPANET must first obtain DARPA and DCA approval. Such networks are connected to the DDN through a “gateway” computer which manages communication between the LAN or non-DDN net and the ARPANET. DARPA treats gateways as regular hosts, so the procedure for registering a gateway is the same as for hosts.

The subscriber must obtain a network number for each LAN from the NIC. Within such a “private network”, subscribers can assign their own host names and addresses as long as they follow the internet network addressing convention [2]. For more information on registering non-DDN networks, contact HOSTMASTER@SRI-NIC.ARPA online or call (800) 235-3155.


3.4.4 User Registration

The DDN PMO and DARPA have authorized the NIC to register all ARPANET users, and to maintain this information in the NIC WHOIS database. This database serves as an online “white pages” service for ARPANET users [6].

The Host Administrator for each host is responsible for registering the users of his or her host with the NIC. This is done electronically over the network, so the Host Administrator is required to have a network mailbox.

Users may be registered either by sending filled-in templates to the NIC through electronic mail, or by using the NIC REGISTER system. This section describes the procedures a Host Administrator should follow to register users. NIC Registration Template

To register by electronic mail, FTP a copy of the registration template(pathname NETINFO:USER-TEMPLATE.TXT, see Figure 3-5) from SRI-NIC ( Complete one template for each individual and separate the templates by a blank line. Fill in all the relevant fields as shown below.
Instructions for completing the template are included in the template file. It is important that you use the NIC template and adhere to the same data-entry style shown. This will allow automatic input of the data into the WHOIS database. The NIC will not accept data that is not in the specified template format.
FULL NAME: Coleman, Jr., Arthur F.
U.S. MAIL ADDRESS: SRI International
333 Ravenswood Avenue
Menlo Park, CA 94025
PHONE: (415) 859-0000

Figure 3-5: Sample User Registration Template


The Host Administrator may send his users blank templates to fill out. Users should return the completed templates to the Host Administrator who will accumulate them in a single file. He will review the lists (as he is responsible for the authorization of registered users on his hosts), and send the files as online messages to REGISTRAR@SRI-NIC.ARPA.

If the list is too long for a given mail system to process, the Host Administrator may break the lists arbitrarily (between templates) and send them as a set of messages. If the lists are broken up, the subject field of each message should specify this, e.g., Part 1 of 4, Part 2 of 4, etc. To assure that the NIC mail system will be able to process the message, never send a message of over 50,000 characters (100 templates). Full instructions for registering users may be obtained from the NIC.

NOTE: Registering ARPANET users with the NIC for the WHOIS database is a separate process from registering users for ARPANET TAC access. NIC REGISTER Program

REGISTER is a program running on SRI-NIC that will allow users to interactively register themselves in the WHOIS database. Contact the NIC for details on using this program.


3.4.5 ARPANET TAC Access Registration

ARPANET TAC users must be authorized for network access by the “Responsible Person” (RP) in their organization. Once users have been given permission by the RP to use an ARPANET TAC, the RP or his delegate, or the user himself may enter user registration data into the ARPANET TAC User Database (UDB), using the User Database Tool located at host USC-ISI. The database is downloaded regularly to several “login hosts” throughout the net. For information on using the database tool, the RP or the user should obtain and read ARPANET Access Control, User Manual for the User Database Tool [7] available in hardcopy or online from the NIC.

NOTE: ARPANET TAC usernames and passwords must be changed every 6 months as they will be invalid after that time. The user may make this change himself, once he has been given permission to be a TAC user. However, the change must be made within the 6 month time period or permission to be a TAC user will again need to be assigned by an RP.



A special set of DoD Internet protocols has been developed and implemented on the ARPANET. The most important of these are the Transmission Control Protocol (TCP) and the Internet Protocol (IP). These protocols govern the handling of internet communication, and must be implemented on each host or host interface before connecting to the network.

Each site has the choice of implementing its own version of the protocols, adapting a public domain version of the protocols, or purchasing an implementation from a commercial vendor. This section discusses some aids to help subscribers choose the best approach based upon their needs.

NOTE: Protocols approved for use on the DDN are issued as official DoD Military Standards (MIL STDs). The ARPANET is an experimental network and may choose to implement experimental ARPANET protocols. These may be ARPANET standards, i.e., required on the ARPANET, but may not be MIL STDs or official DoD protocols.


4.1 DDN Protocol Handbook

The 1985 DDN Protocol Handbook [8] describes specifications for MIL STD communication protocols, ARPANET standard protocols, experimental protocols, and de facto protocols in use on the DDN and the DARPA Internet. It also includes background information, policy information, implementation guidelines, and instructions on how to obtain other protocol information of interest.

The primary purpose of the Handbook is to serve as a reference guide for those planning to implement the DoD suite of protocols on various computers to be attached to the ARPANET or the DDN. It is an essential reference tool for sites bringing hosts onto the network. The Handbook is a multi-volume set published by the NIC and is available from the NIC for $110.00 prepaid, or from the Defense Technical Information Center (DTIC).


4.2 TCP/IP Implementations and Vendors Guide

The TCP/IP Implementations and Vendors Guide [9] is a guide to commercially available implementations of the TCP/IP protocols, including public domain implementations. It is published for informational purposes only by the DDN Network Information Center at SRI International on behalf of the DDN PMO and in no way endorses or officially recommends any implementation or product on the part of DCA, DARPA, the DoD, or the NIC. The Guide is useful for finding out what public domain and commercial implementations of protocols are available.


4.3 RFCs

Before a proposed protocol is accepted for use on the DARPA Internet, it is discussed, reviewed, and often revised by members of the Internet Advisory Board, its Task Force members and other interested parties. This dialog is captured in a set of technical notes known as Requests For Comments, or RFCs.

Individuals who wish to be added to the online RFC notification list should send a message to NIC@SRI-NIC.ARPA requesting that their names be added to the distribution list.

RFCs can also be FTPed from SRI-NIC, using the pathname RFC:RFCnnn.TXT, where “nnn” is the RFC number; also available is the file RFC:RFC-INDEX.TXT, an index to RFCs. See Section 6.1.4 for information on ordering hardcopies of RFCs.



As the ARPANET is an experimental network, there may be occasions when site researchers or representatives wish to make temporary or permanent changes in the host or node software or hardware. Host software may be modified without DDN PMO approval; node software may not. Node equipment is owned and managed by the DDN. Any changes require proper paperwork and sufficient time to transact.

NOTE: PSN hardware and software may not be modified without DDN and DARPA approval. Requests for such changes must be made through the proper administrative channels.


5.1 Subscriber Software and Hardware Modification Requests

Requests for node or backbone software modifications or bug fixes should be sent to the ARPANET Monitoring Center (AMC) at BBN Communications Corporation (BBNCC; see Section 6.2). BBNCC, acting on behalf of DARPA, will prepare a Patch Note and submit it to the DDN Configuration Control Group (CCG) for approval. The CCG will evaluate the request, and if approved, will forward it to DCA Code B643 for implementation. (See Figure 5-1).



5.2 ARPANET Software/Node Modification Procedures

From time to time patches to, or new versions of, node software are released by the DDN PMO. Occasionally these require adjustments to the protocol implementations at the host end. In general, official backbone program changes that may affect hosts or users will be announced through a DDN Management Bulletin (an official online mail notification issued by the NIC on behalf of the DDN PMO), and coordinated with site personnel prior to implementation by the DDN.




6.1 DDN Network Information Center

The DDN Network Information Center, located at SRI International, Menlo Park, CA, is funded by the DDN PMO to provide general user assistance and information services to DDN and ARPANET subscribers and new users.

NIC personnel work closely with DARPA, DDN, BBNCC, network site representatives, network protocol groups, vendors, contractors, government agencies, and military sponsors to provide potential subscribers and new users with pertinent network information. The NIC also serves as the DDN Protocol Repository. Listed below are some of the services provided by the NIC that may be of interest to new subscribers.


6.1.1 User Assistance Service

The NIC provides user assistance services by telephone, U.S. mail, and electronic mail. NIC staff can answer subscriber questions related to connecting a host to the net, or general questions about using the net, and can make referrals to the appropriate network representative for administrative and technical questions. Additionally, the NIC is the source for official ARPANET protocol documents (other than MIL STDs), and is the network repository for RFCs and other technical documents.

The NIC User Assistance “hotline” telephone service is available Monday – Friday, 7 am to 4 pm, Pacific time. The number is:

(800) 235-3155


6.1.2 NIC Contacts

Correspondence may be sent by electronic or U.S. mail to:

Title Network Mailbox

User Assistance NIC@SRI-NIC.ARPA
Network Naming and Addressing HOSTMASTER@SRI-NIC.ARPA
Manager, NIC (415) 859-6287 FEINLER@SRI-NIC.ARPA

U.S. Mail Address
DDN Network Information Center
SRI International, Room EJ291
333 Ravenswood Avenue
Menlo Park, CA 94025


6.1.3 Online Servers TACNEWS

TACNEWS is a NIC online service that offers login help to TAC users, includes the current list of ARPANET and MILNET TAC phone numbers, and provides a mechanism for reading the DDN Newsletters and the DDN Management Bulletins. Users should read these publications regularly to stay current on DDN policies, announcements, and network news items. Access TACNEWS by logging into a TAC and typing “@n<Return>” or by using the TELNET service to connect to host SRI-NIC ( and typing “tacnews<Return>”. WHOIS/NICNAME

WHOIS/NICNAME is a NIC program that provides an electronic “white pages” of network users. It lists the name, network mailbox, U.S. mail address, telephone number, and host for all registered users.

This program is available on the SRI-NIC host ( and can be reached by opening a TELNET connection and then by typing “whois<Return>”.

WHOIS/NICNAME may also be run from a local host. WHOIS/NICNAME user programs for several operating systems are available from the NIC. Contact the NIC for copies and see RFC 954 [6] for details. Note that on most UNIX systems the service is invoked by typing “nicname <Return>.” Host Name Server

The NIC provides an internet Host Name Server on SRI-NIC ( port 101 decimal. This server delivers machine-translatable host name/address/attribute information describing networks, gateways, and hosts within the DDN. The server can deliver a single response or the entire host table, depending upon the type of query sent. The server provides the information outlined in RFC 952 [3] and is itself described in RFC 953 [10]. For further information on using the Host Name Server, make a TELNET connection to SRI-NIC port 101 and type “help<Return>”.


6.1.4 Documents

The NIC edits, publishes, and distributes several documents useful to ARPANET site representatives and users. Listed here are those of interest to new or potential subscribers and users. (See Section 8 for additional references.)

Documents of interest to subscribers:


The DDN Protocol Handbook [8] is a three-volume reference set of experimental ARPANET and official DoD network protocols together with implementation details and related background information. It can be ordered prepaid from the NIC for $110.00, or from DTIC.

NOTE: The NIC publishes the DDN Protocol Handbook as a source book for the convenience of implementers and network researchers. Individual DoD military standards (MIL STDs) for protocols in use on the DDN are officially issued by, and also are available from, the Naval Publications and Forms Center, Code 3015, 5801
Tabor Ave., Philadelphia, PA 19120, (215) 697-3321.


The Vendors Guide lists software and hardware implementations of the DDN protocols, based upon information supplied by vendors. It is available at no charge from the NIC for information purposes only. Entry on this list does not imply endorsement.

RFCs (hardcopies)

Requests for Comments or RFCs are a set of network technical notes. Hardcopies of RFCs can be ordered from the NIC. There is a $5.00 copying charge for each RFC under 100 pages, and a $10.00 copying charge for each RFC over 100 pages. Orders should be prepaid to the NIC.
Documents of interest to both subscribers and users:


The DDN New User Guide [12] is a brief guide to DDN network tools and services designed to introduce users to the network. Available from the NIC or DTIC.


The DDN Directory [11] is a directory of users and hosts on the network. It includes the name, address, network mailbox, and telephone number for each registered network user (as of 1984). Available for $10.00 prepaid to SRI International, DDN Network Information Center, Room EJ291, Menlo Park, CA 94025, or from the Defense Technical Information Center (DTIC).


6.1.5 Online Files

The NIC maintains a number of online files which are available to network subscribers via the ARPANET. These files contain information about protocols, site personnel, hosts, and other subjects relevant to network users. For more information on available public-access files, see the DDN New User Guide [12], or contact the NIC User Assistance service.


6.2 ARPANET Network Monitoring Center

The ARPANET Network Monitoring Center (AMC) is located within the Network Operations Situation Room at BBN Communications Corporation (BBNCC) in Cambridge, MA. AMC staff provide operations support for the ARPANET. The AMC concentrates on real-time network management of the ARPANET by maximizing the network operating efficiency. It provides:

  • – Operations and technical support
  • – Configuration management and software maintenance and enhancement
  • – Hardware maintenance
  • – Hardware requirements
  • – Network experiments.

AMC services include remote status monitoring, coordination of network outage troubleshooting efforts, and 24-hour-per-day/7-day-per-week technical assistance for network users. The AMC typically works on backbone-related outages consisting of node and circuit problems, and provides help in determining whether or not host connectivity problems are network-related.

Contact the AMC for all network hardware problems, for hardware field service, problems with host interfaces, or suspected node software problems. Inform the AMC of any extended outages at your site, especially those that may affect the PSN, and consult with them before carrying out any experiment that may affect the network.

Users are encouraged to telephone the AMC rather than send electronic mail, as this assures that the AMC will get all the necessary information, and usually produces a faster response. (Note, however, that all orders for backbone service must originate from the PMO.)

NOTE: The AMC will accept collect calls to (617) 661-0100.


6.2.1 AMC Contacts

Title Telephone Network Mailbox

Network Monitoring Center (617) 661-0100 CONTROL@BBN-UNIX.ARPA
(617) 497-3571*
New Subscriber Liaison (617) 497-2633* DIPANFILO@BBN-UNIX.ARPA
Manager, NOC (617) 497-3117* JBURKE@BBN-UNIX.ARPA
* Now exchange 873 (May 89)


6.3 Complaint Center/Unsatisfactory Service Reports

A complaint center terminal is maintained at the AMC to monitor messages from users reporting problems or seeking assistance. (Send electronic mail to GRIPES@BBN-UNIX.ARPA.) An additional channel for reporting unsatisfactory service is the ARPANET Unsatisfactory Service Report (USR), which is the formal mechanism for reporting operational deficiencies in the ARPANET backbone. Problems or complaints which cannot be resolved through normal channels should be reported by means of the USR. This may include (but is not limited to) the following:

  • – Excessive response time
  • – Inadequate restoral procedures
  • – Unsatisfactory maintenance support.

The Subscriber must decide when service has reached an unsatisfactory point, and must initiate the USR if the problem cannot be resolved. Send the report online or by U.S. mail (see 7.1 for address) to DCA Code B652, with information copies to the AMC (BBNCC) and any other activity deemed appropriate by the originator.




7.1 DDN PMO Contacts

Code Title Telephone* Network Mailbox

B600 Program Manager 285-5010 DCAB600@DDN1.ARPA
B641 Subscriber Requirements &
Integration Branch 285-5027 DCAB641@DDN1.ARPA
B602B Data Base and
Configuration Mgt. Branch 285-5017 DCAB602B@DDN1.ARPA
B652 Packet Switch Operations Branch 285-5225 DCAB652@DDN1.ARPA

[* Area Code (703), Autovon 356-xxxx]

Postal Mail: Defense Communications Agency
B652, Packet Switch Operations Branch
Washington, DC 20305


7.2 DARPA Contacts

Title Telephone Network Mailbox

Internet Advisory Board (202) 694-4002 PERRY@IPTO.ARPA
(213) 822-1511 POSTEL@USC-ISIF.ARPA
(703) 883-6000 CPERRY@MITRE.ARPA

Postal Mail: Defense Advanced Research Projects Agency
Information Processing Techniques Office
Attn: Lt. Col. Bob E. Baker
1400 Wilson Boulevard
Arlington, VA 22209-2389


7.3 Contacts for Specific Services

Telephone Network Mailbox

ARPANET Access Authorization (202) 694-3049 BAKER@USC-ISI.ARPA
ARPANET TAC Access Administration (202) 694-3049 BAKER@USC-ISI.ARPA
ARPANET New TAC Requests (202) 694-3049 BAKER@USC-ISI.ARPA
ARPANET Policy and Administration (202) 694-5050 KIGGENS@IPTO.ARPA
Backbone Equipment Information (617) 497-2633* DIPANFILO@BBN-UNIX.ARPA
Backbone Installation Schedule (703) 285-5231 ARPANETMGR@DDN1.ARPA
ARPANET Service Requests (202) 694-5921 BOWERS@USC-ISI.ARPA
General ARPANET Mgt. Information (703) 285-5233 ARPANETMGR@DDN1.ARPA
General ARPANET Information (800) 235-3155 NIC@SRI-NIC.ARPA
Node Problems (617) 661-0100 CONTROL@BBN-UNIX.ARPA
8 Now 873-2633 (May 89)



Below is a bibliography of manuals and documents that are mentioned in this document and are helpful in understanding the ARPANET and DDN. The ordering number is given, when known, for items that may be ordered from the Defense Technical Information Center (DTIC).

Documents marked (NIC) are available in hardcopy from the NIC; documents marked (PMO) are available from the DDN PMO. Files available online at the NIC (host SRI-NIC, are indicated by giving the pathname in the form [DIRECTORY:FILENAME.EXTENSION]. These files may be copied across the network by using the File Transfer Protocol program (FTP). Call the NIC if you need assistance with FTP.


8.1 Cited References

[1] DDN Subscriber Interface Guide. Defense Data Network, Program
Management Office, Defense Communications Agency, Washington, DC,
1983. (NIC) [AD-A132 877/2]

[2] RFC 796, Address Mappings. University of Southern California,
Information Sciences Institute, Marina del Rey, CA, September 1981.

[3] RFC 952, DoD Internet Host Table. SRI International, Menlo Park, CA,
October 1985. (NIC) [RFC:RFC952.TXT]

[4] RFC 920, Domain Requirements. University of Southern California,
Information Sciences Institute, Marina del Rey, CA, October 1984.

[5] RFC 921, Domain Name System Implementation Schedule – Revised.
University of Southern California, Information Sciences Institute,
Marina del Rey, CA, October 1984. (NIC) [RFC:RFC921.TXT]

[6] RFC 954, NICNAME/WHOIS. SRI International, Menlo Park, CA, October
1985. (NIC) [RFC:RFC954.TXT]

[7] ARPANET Access Control, User Manual for the User Database Tool.
Defense Advanced Research Projects Agency, Arlington, VA, July 1984.

[8] DDN Protocol Handbook. DDN Network Information Center, SRI
International, Menlo Park, CA, November 1985. (NIC, $110.00 domestic,
$130.00 overseas, prepaid)

[9] TCP/IP Implementations and Vendors Guide. DDN Network Information
Center, SRI International, Menlo Park, CA, 1985. (NIC) [NETINFO:TCP-

[10] RFC 953, Hostnames Server. SRI International, Menlo Park, CA, October
1985. (NIC) [RFC:RFC953.TXT]

[11] DDN Directory. DDN Network Information Center, SRI International,
Menlo Park, CA, 1984. (NIC, $10.00 prepaid) [AD-A148 213]

[12] DDN New User Guide. DDN Network Information Center, SRI
International, Menlo Park, CA, 1985. (NIC)


8.2 Additional References

ARPANET Access Control, User Guide for the User Database Tool. Defense
Advanced Research Projects Agency, Arlington, VA, July 1984. (NIC)

Assigned Numbers, Information Sciences Institute, University of Southern
California, Marina del Rey, CA. (NIC) [RFC:ASSIGNED-NUMBERS.TXT]

DDN Defense Data Network Brochure. Defense Data Network, Program
Management Office, Defense Communications Agency, Washington, DC, 1984.

DDN Subscriber Security Guide. Defense Data Network, Program Management
Office, Defense Communications Agency, Washington, DC, 1983. (NIC)
[AD-A152 524]

DDN User’s Planning Guide. Defense Data Network, Program Management
Office, Defense Communications Agency, Washington, DC, 1985. (PMO)

DDN X.25 Host Interface Specification. Defense Data Network, Program
Management Office, Defense Communications Agency, Washington, DC, 1983.
(NIC) [NETINFO:X25.DOC] [AD-A137 427]

and Newman Inc., Cambridge, MA, 1981. [AD-A115-440]

Instructions for Network User Registration Drive (MILNET). DDN Network
Information Center, SRI International, Menlo Park, CA, October 1983. (NIC)

Submission of Telecommunications Service Requests, DCA Circular 310-130-1.
Defense Communications Agency, Washington, DC, 1983. (PMO)

TAC Users’ Guide, Report No. 4780. Bolt Beranek and Newman Inc.,
Cambridge, MA, 1982. (NIC) [NETINFO:TAC-USER.DOC] [AD-A147 366]



Listed here are terms and acronyms used in this document. Definitions are given for terms whereas organizational acronyms are generally just expanded to their full length.

  • AMC ARPANET Network Monitoring Center, located at BBNCC, Cambridge, MA.
  • ARPA see DARPA.
  • ARPANET DARPA’s packet-switched host-to-host digital communications network which links a wide variety of DoD-sponsored computers at research centers around the world.
  • BBNCC Bolt Beranek and Newman Communications Corporation; the company that provides network node hardware, software and field servicing, and manages the ARPANET Network Monitoring Center. Early contributor to the development of the DDN.
  • backbone The nodes (see below) and the leased telephone lines and satellites connecting them, which form the core of the DDN.
  • CCG DCA Configuration Control Group, the group which screens and approves changes to the backbone configuration as needed.
  • DARPA Defense Advanced Research Projects Agency.
  • DCA Defense Communications Agency.
  • DCEC Defense Communications Engineering Center.
  • DDN Defense Data Network; the DoD’s host-to-host, packet-switched data communications network. The DDN interconnects several military networks, one of which is the ARPANET.
  • DDN PMO Defense Data Network Program Management Office; the office within the DCA responsible for management of the DDN.
  • DECCO Defense Commercial Communications Office.
  • DoD Department of Defense.
  • Feeder TSR Preliminary Telecommunications Service Request (TSR) used by DARPA to request ARPANET service from the DDN PMO.
  • FTP File Transfer Protocol; the network protocol that allows host-to-host file transfer across the network without disrupting the format of the file being transferred.
  • gateway A special computer which interconnects two networks, performs any needed protocol conversion or address translation, and administers access control between them.
  • HAdmin Host Administrator; see Appendix for a list of Host Administrator duties.
  • HAF Host Approved Form provided by DARPA IPTO.
  • host Computer directly connected to a PSN port on the DDN.
  • HOSTMASTER Mailbox at the NIC for host registration, name, address, and other changes to information in the DDN host table.
  • hostname Name which officially identifies a host computer attached to the DDN.
  • IMP Interface Message Processor; now called Packet Switch Node or PSN, which see.
  • INCO INstallation Check Out kits; containers of node spare parts.
  • Internet Protocol Standard that allows Internet networks running different protocols to connect and communicate with each other.
  • IPTO Information Processing Techniques Office; the DARPA office that administers and sets policy for the ARPANET.
  • ISI University of Southern California Information Sciences Institute.
  • LAN Local Area Network; a private network that connects data processing equipment in a limited geographic area (e.g. an office, building, or complex of buildings).
  • M/A-COM M/A-COM Linkabit, Incorporated.
  • MIT Massachusetts Institute of Technology.
  • MIL-STD Military Standard; the specification for a standard (including network protocols) that is to be implemented for a military system or as a product used by the DoD.
  • MILNET Unclassified operational MILitary NETwork, which is part of the DDN.
  • MITRE MITRE Corporation.
  • NCAN Network Change Acknowledgement Notice.
  • NCD Network Change Directive.
  • NCR Network Change Request.
  • NIC Network Information Center located at SRI International, Menlo Park, CA, under contract to the DDN PMO.
  • node Packet switch; a PSN, TAC, mail bridge, or combination of these.
  • NSC Node Site Coordinator; local DDN representative assigned to a TAC or PSN who is responsible for access control and accountability for all DDN-owned hardware, software and circuits located at the node site. (See Appendix for a list of NSC duties).
  • OSD Office of the Secretary of Defense.
  • PDC Program Designator Code; code used to identify the funding activity responsible for reimbursing the cost of backbone charges.
  • PMO Program Management Office of the DDN.
  • POC Point Of Contact.
  • PSN Packet Switch Node; a store-and-forward packet switch to which several host computers can be connected.
  • REGISTRAR Mailbox at the NIC for user registration, name, address, and other changes to information in the registration (WHOIS) database.
  • RFC Requests For Comments; a set of technical notes describing networking research carried out by the DARPA network community (available from the NIC).
  • RP Responsible Person; person appointed by DARPA to register ARPANET TAC users in a particular organization.
  • site Organization or facility where host or node equipment is located.
  • SMTP Simple Mail Transfer Protocol; the official DoD mail protocol.
  • socket Logical address of a port providing access to a specific device or service on a host.
  • SRI-NIC The DDN Network Information Center host computer, located at SRI International, Menlo Park, CA. This host is multi-homed on both the ARPANET and the MILNET, and provides information services to both.
  • SRI SRI International; location of the DDN Network Information Center and early contributor to the development of the ARPANET and the DDN.
  • subscriber A system connected to the ARPANET, and the individuals responsible for that system.
  • TAC Terminal Access Controller; a special host attached to a PSN that lets terminals connect directly to the DDN.
  • TAC Access Code Password assigned to TAC users for TAC login.
  • TAC USER ID Alphanumeric character string that identifies a TAC user upon TAC login.
  • TCP/IP Transmission Control Protocol/Internet Protocol; two of the DoD standard network protocols.
  • TELCO Telephone company.
  • TELNET DoD protocol for opening a transparent (virtual terminal) connection from one host to another. Also refers to the program implementation that provides this service.
  • TIP Terminal Interface Processor; predecessor of the TAC, serving a similar function.
  • TSO Telecommunications Service Order; DCA authorization to start, change, or discontinue circuits or trunks.
  • TSR Telecommunications Service Request; a valid, approved and funded telecommunications service requirement submitted by DCA through DECCO to the telephone companies.
  • UCL University College London, England.
  • UCLA University of California, Los Angeles.
  • UDB User Database Tool for registering ARPANET users for TAC Access.
  • USR Unsatisfactory Service Report; report sent to the DDN PMO by a network subscriber to report unsatisfactory network service.



This appendix describes the duties of ARPANET personnel at host and node locations.

1. Responsible Person

The person in a particular organization appointed by DARPA who has authority to give ARPANET users permission for TAC access is called a Responsible Person (RP). RP’s are representatives of organizations involved in DARPA research programs.


a. For ARPANET TAC Access, a \Responsible Person” has been identified in each government and contractor organization whose members need to use ARPANET TACs. The Responsible Person grants permission to use an APRANET TAC to members of his or her organization by updating the ARPANET user database (which is different from the NIC User Registration database). A \User Database Tool” is used by the Responsible Persons or their designated alternates to add, delete, and change information describing authorized ARPANET TAC users.

b. The motivation for the organization-oriented approach to authorization of TAC usage is to put the authorization in the hands of the people best able to validate the requirement for access. The \Responsible Persons” must make sure that TAC access is granted only to people who are authorized to use the ARPANET, and that such access conforms to guidelines on the purpose of the ARPANET and the proper use of ARPANET TACs.

2. Host Administrator

The Host Administrator (HAdmin) has administrative responsibility for the policies, practices, and concerns of a host or hosts connected to the DDN, including responsibility for that host’s DDN users.


a. Assists the DDN PMO by ensuring that network policies and procedures are observed by the users. Ensures that all of his or her host users, who are using the network or the network TACs, have been authorized for ARPANET access and are registered in the NIC User Registration database.

b. Manages the network access control procedures and password system, and is responsible for reporting network-related host break-ins and assisting with investigative effort as needed.

c. Coordinates with the DDN PMO on installation and removal of hosts on the DDN; and also coordinates installation of, or changes to, host software that has direct or indirect impact on the DDN. The HAdmin provides the DDN PMO and the NIC with required descriptive information for each new host addition or host change, and coordinates the host certification procedure with the DDN PMO prior to passing traffic on the network. The HAdmin is responsible for the proper implementation an maintenance of DDN protocols at the host level.

d. Serves as local point of contact for his or her respective hosts and local users and coordinates suspected network-related problems directly with the network monitoring center.

e. Provides network information to the NIC, and assists local users and other interested personnel with network-related matters.

3. Node Site Coordinator

The Node Site Coordinator is designated as having site access control, DDN hardware an software accountability, and coordination responsibility for the DDN circuits an equipment located at the DDN Node Site.


a. Directly interacts with DDN management channels and the network monitoring center on network communications operational matters.

b. Provides the node site’s single point of contact for network backbone matters. (Delegation of responsibilities to individuals within the node site is the NSC’s prerogative, however, the NSC is still that node site’s single point of contact for network backbone matters).

c. Accountable for DDN node hardware and software (cassette tapes).

d. Authorizes and ensures personnel access to the node site.

e. Supervises, assists, coordinates or monitors the installation and implementation of node hardware, software, and circuits.

f. Performs administrative functions, as required.

g. Ensures the node site has a single place of contact for the DDN or its representatives to obtain local site assistance on a 24-hour, 7-day a week basis, when required. (In the isolated case that the node site is located in a facility that is not manned on a 24-hour, 7-day a week basis, the NSC ensures that someone at the place of contact can obtain local site assistance within two hours).

h. Provides for accountability and access control of the PSN/TAC system cassette tapes (IMPLOD and SYSTEM).

i. Provides for custodial care of the on-site container(s) of node spare parts, known as INCO (INstallation Check Out) kits. (Normally, these kits are located at selected overseas sites).

j. Provides site coordination and authorizes personnel with site access for installation, removal, and modifications to DDN hardware or circuits, for emergency or scheduled preventive maintenance, as directed by DCA or the designated network monitoring center.

k. Ensures that local site assistance is provided, when required by the network monitoring center, for corrective actions during node hardware or circuit degradation or outages, which are beyond the capability of the network monitoring center to correct. For instance, on instruction from the network monitoring center due to PSN or circuit failure, the local site representative may be requested to press reset buttons on the back of PSN/TAC chassis, observe status lights, insert/remove the tape cassette (normally always in reader), switch cables, loop modems (normally on TAC connections), loop modems on covered circuits in selected locations or coordinate restoration actions with local field-site communications technicians/organizations.

l. Ensures that DDN hardware, software, or circuits are not altered, moved or tampered with, without proper authorization.

m. Monitors investigative reports related to DDN hardware and software located at the node site.

n. Performs limited administrative functions such as: (1) maintaining and being aware of operating instructions issued by DCA, the Network Information Center (NIC) on behalf of the DDN PMO, and the network monitoring center; (2) maintaining a contact list of telephone numbers for the local TELCO service office or DCS technical control, network monitoring center, and the Host Administrator for each host connected to the DDN PSN(s) at that node site; (3) maintaining a \Node Site Access Roster,” which lists all personnel authorized to have access to the node site and associated equipment.


Access controls
host 4
AMC 15
access and use 4
description 3
ARPANET Network Monitoring Center
collect calls 15
description 15
telephone numbers 15

Bug fixes 11

CCG 11, 21
Unsatisfactory Service Reports
Configuration Control Group 11
Costs 6

addresses and phone numbers
mailing address 6
mission 3
responsibilities 3
description 3
responsibilities 3
Directory 15
Network Information Center
New User Guide 15
Protocol Handbook 14
DDN Network Information Center
toll free number 13
contacts 17
mailing address 6
Defense Communications Agency 3
Domains 7

Feeder TSR 6

Gateway registration 7

Host address 7
Host Administrator
duties 23
Host Name Server 14
function 7
Host table
updating 7

responsibilities 3
task forces 3
Information Processing Techniques
see also IPTO 3
Internet Research Program
mission 3
responsibilities 3, 5

Local Area Networks 7


Naming domains 7
confirmation 5
generation of 5
Network Monitoring Center 15
Network Operations Center
telephone numbers 15
getting Host tables from 7
installation 5
problems 15
software modifications 11
Node Site Coordinator
duties 23
requirement for 5
requirement for 5

documentation 9
Internet 9
vendors 9
modifications 11
port assignment 7
port changes 7
relation to network number 7

Registration template
user 7
Registration 7
host 7
TAC access 8
user 7
user – REGISTER 8
user – template 7
Registration template
host 7
Host Administrator 7
Registration template,
user 7
Request For Comments 9
Responsible Person 4
duties 23
hardcopies 14

Software modifications 11
Subscriber access
time required 5
Subscriber access procedures 5

Implementations and Vendors
Guide 14
Telephone numbers 17
Terminal connection 7
function 5
receipt of 5
function 5
obtaining 5
submission 5

registration 8
Unsatisfactory Service Reports
User Data Base
User Data Base
registration 8

Vendors Guide


Tagged , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *