💾 Archived View for gemini.spam.works › mirrors › textfiles › hacking › INTERNET › arpa.man captured on 2022-03-01 at 15:40:04.
-=-=-=-=-=-=-
NIC 50003
ARPANET INFORMATION BROCHURE
DECEMBER 1985
ARPANET INFORMATION BROCHURE
DECEMBER 1985
Editor:
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
TABLE OF CONTENTS
ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . III
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
SECTION 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . 1
1.1. How To Use This Document . . . . . . . . . . . . . . 1
SECTION 2. ARPANET MANAGEMENT AND POLICIES . . . . . . . . . . . . 3
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
3.4.4.1. NIC Registration Template . . . . . . . . . . . 7
3.4.4.2. 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
SECTION 5. HARDWARE AND SOFTWARE MODIFICATIONS . . . . . . . . . . 11
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
6.1.3.1. TACNEWS . . . . . . . . . . . . . . . . . . . . 14
6.1.3.2. WHOIS/NICNAME . . . . . . . . . . . . . . . . . 14
6.1.3.3. 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
ACKNOWLEDGEMENTS
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.
ABSTRACT
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.
SECTION 1. INTRODUCTION
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.
SECTION 2. ARPANET MANAGEMENT AND POLICIES
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.
Figure 2-1: Hardware and Configuration of the DDN
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.
DoD
________________|________________
| |
DCA DARPA
| |
DDN PMO IPTO
| |
(operational management) (administration, policy)
(security) (configuration, access)
|________________ ________________|
|
ARPANET
Figure 2-2: Management of the ARPANET
2.2.1 DARPA/IPTO
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.
SECTION 3. SUBSCRIBER ACCESS PROCEDURES
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.
New Subscriber Request
|
DCA Code B641
|
ARPANET Coordinator, DARPA
|
Feeder TSR and HAF
|
DARPA IPTO Approval
|
DCA Code B652 Approval
|
DCA Code B643
|
Requester <------- TSR Issued
Notified TSO Issued --------> DECCO
|
DCA Code B652
Provides Host Data
|
DCA Code B642
|
NCR
|
DCA Code B652
Approval
|
NCD
|
______________________|______________________
| | |
SRI NIC Requester AMC
| Notified |
Host Table Change NCAN
|
DCA Code B652
AMC: ARPANET Monitoring Center NCD: Network Change Directive
DECCO: Defense Commercial Comm. Office NCR: Network Change Request
HAF: Host Approved Form SRI NIC: Network Information Ctr.
IPTO: Info. Process. Techniques Office TSO: Telecomm. Service Order
NCAN: Network Change Ack. Notice TSR: Telecomm. Service Request
Figure 3-1: ARPANET New Subscriber Request Flow
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.
FEEDER TSR TEMPLATE (Sample)
(1) (2) (3)
TSR INFORMATION TYPE OF ACTION
ITEM NO. START AMEND REHOME CANCEL
--- ----------- ----------------------------
101 LEAVE BLANK
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.
110 FULL DUPLEX
111 Enter the data rate (2.4KB, 1.2KB,
4.8KB, 9.6KB, 50KB, 56KB, 100KB) of
the requested service.
112 FULL PERIOD
115 NO SIGNALLING X X
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.
117 LEAVE BLANK
118 LEAVE BLANK
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.
120B TO BE DETERMINED BY DCA
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.
419 DECCO SCOTT AFB
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.
510 LEAVE BLANK
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
Attn: ARPANET COORDINATOR
1400 Wilson Boulevard, 7th Floor
Arlington, Virginia 22209
Telephone
Phone: (202) 694-5921
Network Mailbox
BOWERS@USC-ISI.ARPA
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)
HOSTNAME: DDN1
NETWORK ADDRESS: 10.1.0.25
LOCATION: Bolt Beranek and Newman Inc.
1300 North 17th Street
Suite 400
Arlington, Virginia 22206
CPUTYPE: BBN-C/70
OPERATING SYSTEM: UNIX
NICKNAME: DDN-1
SPONSORING AGENCY: DCA
HOST TYPE: DH
PROTOCOLS: TCP/TELNET,TCP/FTP,TCP/SMTP
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)
NETWORK MAILBOX: chipman@BBNF.ARPA
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.
3.4.4.1 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
(10.0.0.51). 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
AUTHORIZING HOST: SRI-NIC
PRIMARY LOGIN NAME: Coleman
PRIMARY NETWORK MAILBOX: coleman@SRI-NIC.ARPA
ALTERNATE NETWORK MAILBOXES (if any): acoleman@SRI-TSC.ARPA
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.
3.4.4.2 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.
SECTION 4. ARPANET PROTOCOLS
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.
SECTION 5. HARDWARE AND SOFTWARE MODIFICATIONS
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).
DARPA (info copy)
/
User or DARPA Request >--> BBNCC >--> DDN CCG >--> Implementation
Figure 5-1: Modification Request Procedure
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.
SECTION 6. NETWORK INFORMATION SERVICES
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
User Registration, MILNET TAC Access REGISTRAR@SRI-NIC.ARPA
Network Naming and Addressing HOSTMASTER@SRI-NIC.ARPA
Feedback SUGGESTIONS@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
6.1.3.1 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 (10.0.0.51) and typing "tacnews<Return>".
6.1.3.2 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 (10.0.0.51) 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>."
6.1.3.3 Host Name Server
The NIC provides an internet Host Name Server on SRI-NIC (10.0.0.51) 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:
DDN PROTOCOL HANDBOOK
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.
TCP/IP IMPLEMENTATIONS AND VENDORS GUIDE
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:
DDN NEW USER GUIDE
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.
DDN DIRECTORY
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