Unknown Host Numbers
Why the ARPANET sees IMPs that don't officially exist yet
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 ]
AI ELI5
On this page
§1New IMPs Are Tested On the Network
The ARPANET's Interface Message Processors (IMPs) are the network's switching nodes. Before a new IMP is shipped to its permanent location, BBN tests it on the live ARPANET to ensure it works correctly. This is standard procedure.
Before sending a new box to its home, BBN tests it on the real network to make sure it works.
§2IMPs May Use Temporary Numbers During Testing
During testing, a new IMP may be assigned a different IMP number than the one it will have at its final destination. This happens because the official number might already be in use at another site. For example, a TIP destined for ETAC with IMP number 20 was tested at BBN using IMP number 22 (McClellan's number), which resulted in network addresses that do not match official tables.
A new box might wear a different label while being tested, then get its real label when it reaches home.
§3No Host Table Updates Needed
Hosts should expect and tolerate RSTs (reset messages) from these temporary test IMPs. They do not need to update their host tables in response. Official changes are communicated through RFC announcements or updates to Appendix A of BBN Report 1822, the definitive reference on host numbering.
You can ignore strange messages from test boxes. Real changes come by official memo.