Unknown Host Numbers
Why temporary IMP tests can produce unfamiliar host numbers
Alter, R., "Unknown Host Numbers", RFC 305, DOI 10.17487/RFC0305, February 1972, <https://www.rfc-editor.org/info/rfc305>.
@misc{rfc305,
series = {Request for Comments},
number = 305,
howpublished = {RFC 305},
publisher = {RFC Editor},
doi = {10.17487/RFC0305},
url = {https://www.rfc-editor.org/info/rfc305},
author = {R. Alter},
title = {{Unknown Host Numbers}},
pagetotal = 1,
year = 1972,
month = feb,
} RFC text
Network Working Group Ralph Alter
RFC #305 BBN
NIC #9078 23 February 1972
UNKNOWN HOST NUMBERS
--------------------
In response to a recent minor flurry of confusion, it seems worth
announcing publicly the fact that new IMPs are tested (almost
always) on the ARPA Net here at BBN before delivery to the intended
site. Accordingly, sites should not be surprised to receive RFCs
or at least RSTs from IMPs or Hosts they thought didn't exist, or
at least did not exist yet.
Occasionally, IMPs of some given configuration are tested in a
mode where they announce their IMP number as different from what
it will be when finally installed. A variety of reasons may create
such a situation. The latest such occurrence is that a TIP, to be
installed shortly at ETAC with IMP number 20 (replacing the 316
IMP now at ETAC which is number 20) was recently tested here with
McClellan's IMP number (22). (It couldn't be tested with its own
number since the 316 IMP currently at ETAC is using that number.)
The result was RSTs from the TIP (Host 3) at IMP 22 - which is
network address 150 (226 octal or 96 hex).
One site asked if their Host tables needed updating. The answer
is _NO_. We fully expect IMPs tested under these circumstances to be
ignored or CLS'd by some Hosts. We suggest that Host tables (where
they are thought to be necessary) be modified only in response to
official notification from BBN via either an RFC or an update to
Appendix A of BBN Report #1822.
RA/jm
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
ISO Plain Language
On this page
§1Testing New IMPs on the Network
BBN says that it almost always tested new IMPs on the ARPANET before delivering them to their intended sites. As a result, a site might receive a connection request or reset message from an IMP or host it did not expect to exist yet.
BBN tested new network equipment before shipping it to its assigned site. Other sites could see messages from that equipment during the test.
§2Temporary Numbers During Testing
A test IMP could announce a number different from the number planned for its permanent installation. The example is a TIP intended for ETAC, where IMP number 20 was already in use. BBN tested it as number 22, which produced reset messages with network address 150.
The temporary number explained why the messages did not match the official host information.
A test unit could use a number that belonged to another site because its final number was already in use. That could make its network messages look unfamiliar.
§3When to Change Host Tables
BBN answers that sites do not need to update their host tables because of these test messages. Hosts may ignore or close connections from test IMPs. The notice says host tables should be changed only after official notification from BBN, either through an RFC or an update to Appendix A of BBN Report 1822.
Do not change a host table just because a test unit sends a message. Wait for BBN's official notice before changing it.