Computers Connected to IPv4 Address Space
By Doctor Electron
Is there a "who’s who" or "telephone directory" of the computers connected to the internet? Yes and no.
For the "yes," we have lists of allocations of IP address space from the Internet Assigned Numbers Authority [IANA], which delegates tasks to regional registries such as ARIN, RIPENCC and APNIC [RFC 1466]. If one already has an IP address or a host name, further information about that computer may be found at the registries or Directory Name Service (DNS) servers.
For the "no," the computers in these allocated subspaces are largely an unknown group, as far as the author could determine from public records. This report introduces a series of studies on computers connected to the internet in the real world. Subsequent articles will report results in greater detail such as presence of servers and their characteristics, in various IP address subspaces. For example, a vast number of servers do not appear to have DNS entries. This would prevent easy access by casual internet surfers.
An objective is to provide useful information relevant to computer security issues and to people running scanning programs. Private parties will try to fill in the gaps in publicly available information. For example, idefense.com has been creating databases which name organizations utilizing specific address subspaces.
On the other hand, those with malicious intent may conduct studies such as the present "internet census." Therefore, additional security measures may be required as this information is assembled and utilized.
Much like a census of people actually living in households, this paper reports a census of computers actually connected in IP address subspaces. The major result is that most of allocated address space appears to be "empty" or is not readily accessible from the "public internet."
Methods
Random sampling was used to allow estimation of population statistics. Four bytes define a "v4" IP address. Valid IP addresses were randomly generated in a range from 1.0.0.1 to 223.255.255.254 (Class A, B and C ranges) [RFC 1466, RFC 1518, RFC 1519].
Several methods were used to determine the presence of a host at a random address. In any one data collection session, only one of these procedures was conducted with a particular address, to avoid excessive probing of hosts in this survey. Since the random addresses were generated on the fly, it was unlikely any particular host would be probed more than once.
Identification of "ordinary" internet usage required the most simple methods possible to provide a baseline.
1. Single packet ICMP echo requests [RFC 792] elicited echo responses from the randomly selected host which will be denoted "Ping" hosts in these articles.
2. Hosts revealed by response to a ping packet with any error report such as host unreachable or TTL expiration which will be called "Error" reporting hosts.
Note that this supremely simple method immediately raises a question. "Ping" ICMP protocol [RFC 792] and router specifications [e.g., RFC 1812] may require certain hosts and gateways to report errors as in (2) above. For systems that prefer to remain unknown or private, ICMP error reporting reveals their presence, which might be considered as a security issue.
A disadvantage of the ping method is that computers not responding to ping packets, say, because of a firewall, would seem to be not there. By the way, this is a flaw in many scanners. Namely, they will ping first to see if a host is there. Obviously, a host may be there which ignores ping requests.
3. TCP connection to ports commonly used for common services such as FTP, SSH, Telnet, SMTP, HTTP, NetBios (port 139) and HTTPS [RFC 1700]. This method may reveal many computers running such services, whether or not certain security software such as a firewall was installed. Again, in a data collection session, only one port was scanned at each random IP address.
A disadvantage of this method is that computers would be missed if they did not respond to a ping and used non-standard ports of these services or simply blocked packets from unknown clients. Further, this method is limited to AF_INET family packets and protocols. Only established connections were counted, so hosts reporting "connection refused" and the like would not be revealed in these data. Please see "A TCP Ping Reveals Hosts by Connection Refused Error" by the author.
The author wrote the software used for data collection. Descriptions of recipients of address space allocations in Tables 2 and 3 were obtained from IANA.
Results
Table 1 shows where hosts were found. The data is organized according to internet prefixes using the X/8 notation [RFC 1519]. Each entry, 4, 6, 10, 12, etc, denotes an X/8 address space, which includes all addresses X.0.0.1 to X.255.255.254.
The blank entries, 1, 2, 3, 5, etc, appear to be unused, given the present methods.
Table 1: IPv4/8 Addresses Where Hosts Were Found Legend: *, prefixes with activity found with methods not used in this study.
0 1 2 3 4 5 6 7 8 9 A 00 4 6 01 10 12 13* 17* 18 02 20* 24 03 32 33 35 38 04 40* 43 44* 45* 05 51 52 53 55 56* 57 06 61 62 63 64 65 66 67 68 07 79* 08 80 81 85* 09 10 100 11 B 12 NA 128 129 13 130 131 132 133 134 135 136 137 138 139 14 140 141 142 143 144 145 146 147 148 149 15 150 151 152 153 154 155 156 157 158 159 16 160 161 162 163 164 165 166 167 168 169 17 170 171 172 179* 18 188 C 19 192 193 194 195 196 198 199 20 200 202 203 204 205 206 207 208 209 21 210 211 212 213 214 215 216 217 218D 22
Table 2 summarizes the data in relation to IANA descriptions of the address space allocations and the hosts revealed in this study. Data collected thus far using random sampling includes 13,706 Error and 43,370 TCP responses. In general, as sampling proceeded, more than two Error reporters volunteered their IP address for each Ping (n = 5,619) response obtained from a randomly selected address.
Table 2: ICMP and TCP Responses by IP Address Prefix X/8 Description Ping Error TCP004/8 Bolt Beranek and Newman Inc. 19 123 52 006/8 Army Information Systems Center 0 0 14 010/8 IANA-Private Use 0 129 1 012/8 AT&T Bell Laboratories 99 296 180 015/8 Hewlett-Packard Company 1 0 0 018/8 MIT 2 3 4 024/8 ARIN-Cable Block 164 41 347 032/8 Norsk Informasjonsteknologi 4 5 9 033/8 DLA Systems Automation Center 0 4 4 035/8 MERIT Computer Network 1 8 15 038/8 Performance Systems Internation 6 27 11 043/8 Japan Inet 7 1 9 044/8 Amateur Radio Digital Com. 0 0 0 051/8 Dept. of Social Security of UK 0 0 2 052/8 E.I. DuPont de Nemours and Co 1 0 0 053/8 Cap Debis CCS 0 1 0 055/8 Boeing Computer Services (.mil) 0 0 1948 057/8 SITA (French) 3 6 0 061/8 APNIC-Pacific Rim 131 127 456 062/8 RIPENCC-Europe 74 243 410 063/8 ARIN 95 262 459 064/8 ARIN 159 238 1573 065/8 ARIN 107 206 660 066/8 ARIN 132 123 1015 067/8 ARIN 24 188 100 068/8 ARIN 58 13 87 075/8 IANA-Reserved 0 0 1 080/8 RIPENCC-Europe 47 41 198 081/8 RIPENCC-Europe 2 2 15 100/8 IANA-Reserved 0 2 0 128/8 Various Registries 64 118 636 129/8 Various Registries 38 116 950 130/8 Various Registries 36 130 573 131/8 Various Registries 25 76 3044 132/8 Various Registries 11 43 3905 133/8 Various Registries 8 87 171 134/8 Various Registries 27 74 515 135/8 Various Registries 0 4 0 136/8 Various Registries 10 15 186 137/8 Various Registries 15 105 1433 138/8 Various Registries 7 37 231 139/8 Various Registries 13 156 280 140/8 Various Registries 20 60 555 141/8 Various Registries 17 84 165 142/8 Various Registries 25 60 472 143/8 Various Registries 8 40 233 144/8 Various Registries 14 223 332 145/8 Various Registries 2 52 65 146/8 Various Registries 17 92 330 147/8 Various Registries 3 33 814 148/8 Various Registries 14 74 132 149/8 Various Registries 7 31 26 150/8 Various Registries 12 127 249 151/8 Various Registries 23 142 402 152/8 Various Registries 16 132 171 153/8 Various Registries 3 10 283 154/8 Various Registries 1 66 4 155/8 Various Registries 9 33 713 156/8 Various Registries 3 17 87 157/8 Various Registries 12 277 118 158/8 Various Registries 7 78 791 159/8 Various Registries 7 41 399 160/8 Various Registries 10 95 207 161/8 Various Registries 9 46 100 162/8 Various Registries 6 21 334 163/8 Various Registries 10 50 93 164/8 Various Registries 7 78 346 165/8 Various Registries 12 90 141 166/8 Various Registries 12 66 54 167/8 Various Registries 7 37 232 168/8 Various Registries 17 141 191 169/8 Various Registries 3 54 38 170/8 Various Registries 3 46 80 171/8 Various Registries vaskapu .hu 3 6 115 172/8 Various Registries aol.com 106 100 18 188/8 IANA-Reserved (is RIPE) 0 1 0 192/8 Various Registries-MultiRegiona 34 309 154 193/8 RIPENCC-Europe 65 347 346 194/8 RIPENCC-Europe 80 450 359 195/8 RIPENCC-Europe 137 631 586 196/8 Various Registries 12 35 95 198/8 VariousRegistries 49 272 344 199/8 ARIN-North America 48 129 212 200/8 ARIN-Central and South America 117 354 425 202/8 APNIC-Pacific Rim 141 603 516 203/8 APNIC-Pacific Rim 171 479 663 204/8 ARIN-North America 92 255 512 205/8 ARIN-North America 60 203 373 206/8 ARIN-North America 138 433 516 207/8 ARIN-North America 184 385 836 208/8 ARIN-North America 196 330 791 209/8 ARIN-North America 386 381 1945 210/8 APNIC-Pacific Rim 256 531 911 211/8 APNIC-Pacific Rim 502 417 1489 212/8 RIPENCC-Europe 194 579 974 213/8 RIPENCC-Europe 233 388 556 214/8 US-DOD 0 0 2 215/8 US-DOD 0 0 2 216/8 ARIN-North America 454 428 2391 217/8 RIPENCC-Europe 177 180 556 218/8 APNIC-Pacific Rim 63 33 31 219/8 APNIC-Pacific Rim 15 1 1 Column totals are random sample sizes 5619 13706 43370Legend: Data based on random sampling. Other prefixes (e.g., 17/8), known to have networks based on other information, are not included.
IPv4/8 address ranges generally showed all three categories of responsiveness, ping responses, error reports, and TCP connections. In most address ranges listed (rows in Table 2), some connections to each of the ports tested were found across the hosts surveyed. A later article will analyze categories of prefix response patterns and the port distributions in the TCP connections.
ICMP error reports (listed as "Error") may be a useful way to identify hosts that otherwise might not be revealed.
The case of 10/8 is of special interest, because this address space is dubbed as "Private" [RFC 1918]. It might be presumed that hosts identifying themselves with a 10/8 address should not be sending packets out on the internet, yet we do see such hosts are willing to report ICMP errors. This may be normal or faulty network configuration or maybe just plain liar hosts.
If many unrelated private networks use this 10/8 subspace, then we might ask, "Who are these hosts?" A telnet server was found in the random sampling (Table 2). As an ad hoc test beyond the random sampling procedures used in this study, one of these domains was scanned for telnet ports. Various servers were found, connected and in some cases, banners showed host identities by organization name.
Some .mil hosts, Army Information Systems Center (6/8, n = 12), Boeing Computer Services (55/8 , n = 1696) and the apparently US-DOD hosts (214/8, n = 2; 215/8, n = 2) reveal their presence via TCP connections although the networks appear to be meticulous about remaining mute concerning pings or errors such as expiring echo packets or unreachable hosts. It might be assumed that if the administrators of such hosts want their systems to be more "low profile," the obvious choice of using non-standard ports for TCP services might be considered.
In summary, only 101 of 222 (1 to 223, excluding 127/8) IPv4/8 address spaces showed hosts connected to the internet according to the present methods. If the fourteen ranges showing less than ten responses are excluded, only 87 of 222 (39%) of the address space revealed responsive hosts.
Table 3 lists IPv4/8 subspaces where hosts were not found with the current ping and TCP methods. The seemingly large number of such addresses may be interesting in view of current concerns about exhausting address space as more computers come on line.
Table 3: IPv4/8 Addresses Where Hosts Were Not Found
X/8 Description Date000/8 IANA-Reserved Sep-81 001/8 IANA-Reserved Sep-81 002/8 IANA-Reserved Sep-81 003/8 General Electric Company May-94 005/8 IANA-Reserved Jul-95 007/8 IANA-Reserved Apr-95 008/8 Bolt Beranek and Newman Inc. Dec-92 009/8 IBM Aug-92 011/8 DoD Intel Information Systems May-93 013/8 Xerox Corporation Sep-91 014/8 IANA-Public Data Network Jun-91 016/8 Digital Equipment Corporation Nov-94 017/8 Apple Computer Inc. Jul-92 019/8 Ford Motor Company May-95 020/8 Computer Sciences Corporation Oct-94 021/8 DDN-RVN Jul-91 022/8 Defense Information Systems Agency May-93 023/8 IANA-Reserved Jul-95 025/8 Royal Signals and Radar Jan-95 026/8 Defense Information Systems Agency May-95 027/8 IANA-Reserved Apr-95 028/8 DSI-North Jul-92 029/8 Defense Information Systems Agency Jul-91 030/8 Defense Information Systems Agency Jul-91 034/8 Halliburton Company Mar-93 036/8 IANA-Reserved Jul-00 037/8 IANA-Reserved Apr-95 039/8 IANA-Reserved Apr-95 040/8 Eli Lily and Company Jun-94 041/8 IANA-Reserved May-95 042/8 IANA-Reserved Jul-95 044/8 Amateur Radio Digital Com. Jul-92 045/8 Interop Show Network Jan-95 046/8 Bolt Beranek and Newman Inc. Dec-92 047/8 Bell-Northern Research Jan-91 048/8 Prudential Securities Inc. May-95 049/8 Joint Technical Command May-94 050/8 Joint Technical Command May-94 054/8 Merck and Co Inc. Mar-92 056/8 U.S. Postal Service Jun-94 058-060/8 IANA-Reserved Sep-81 069-079/8 IANA-Reserved Sep-81 082-099/8 IANA-Reserved Sep-81 101-126/8 IANA-Reserved Sep-81 127/8 IANA-Reserved (Local Host) Sep-81 173-187/8 IANA-Reserved May-93 189-191/8 IANA-Reserved May-93 197/8 IANA-Reserved May-93 201/8 Reserved-Central and South America May-93 220/8 APNIC 1-Dec 221-223/8 IANA-Reserved Sep-81 Legend: Most of the address space appears to be void of ICMP echo and AF_INET TCP/IP hosts.Discussion
Computers connected to the internet in IPv4 address space were surveyed by analysis of data from randomly selected IP addresses. Connected computers were assessed by (a) ping responses, (b) "volunteer" computers reporting ICMP error data regarding the ping packets sent to other addresses, and (c) established TCP/IP connections to ports 21, 22, 23, 25, 80, 139 or 443.
It may be a surprise that only 39% of the address ranges from 1/8 to 223/8 tested actually showed a significant number of active host computers. The counts tabulated in Table 2 suggest the relative density of hosts comparing among the subspaces (rows) within a Class, as originally defined. For example, 18/8 allocated to MIT shows few hosts (Table 2).
Table 3 implies an agenda of questions no doubt for both white hat and black hat hackers. What exactly is going on in most (the remaining 61%) of the address space? Several possibilities that are not mutually exclusive might be mentioned.
- Tables 2 and 3 indicate much of the address space appears to be allocated for U.S. military and government use. Some of this space may be unused or active with other protocols and/or packet families. One can only surmise that truly massive networks may be involved here.
- Many of the seemingly puzzling entries in Table 3 may be utilized in voice telecommunications where either protocols other than ICMP and TCP are used or packet families other than AF_INET are employed.
- Some of the apparently unused address space (e.g., 201/8) appears to be already allocated for ordinary IPv4 usage and will presumably be occupied by hosts as time passes. This might be the least interesting category.
- A significant number of Table 3 entries which appear to be "unused" may not be linked by routers to exchange packets with the ordinary IPv4 space. If this is true and various entities listed in Table 3 are running networks, then it would seem that this activity is essentially a set of private networks which themselves may be linked by their own routing systems [e.g., see RFC 1930]. If there are such private networks, why are they not listed as such and why do they use address subspaces that might otherwise be used by the "public internet"?
If the foregoing speculation is correct, then we have a set of internets which remain separate by lack of obvious links (gateways) on a shared set of routers. One might wonder what gateways, if any, might link the generally separate systems, including what the public calls "the internet" so that machines in each might talk to each other under the right circumstances (e.g., knowing the gateway or "acceptable" source IP address ranges).
It is clear to the author, as a researcher, that if these computers exist and have their own networks (Table 3), one might say, "These critters may have some explaining to do." In brief, to what extent does Table 3 represent unused address space resources or "private" or even "secret" address space. Certainly the quite simple methods used in the present study, along with the IANA descriptions cited, suggest that there could not have been a serious effort to maintain a "secret" address space.
- Of course, a simple explanation for some Table 3 entries is that these systems do not respond in any manner to ICMP pings and also use non-standard ports for any standard services offered or respond only to packets from "known" addresses.
Good research should provide some answers and many more questions. The next reports in this series will explore these issues in greater detail and present other methods which reveal computers in more X/8 subspaces than found in the present report. The author would appreciate your knowledge and feedback.
A few words for those readers who are running their favorite port scanner. Depending on your purpose, you may want to disable prior host location by use of ping.
If you get results to expand the present effort, please let the author know. You might save time by avoiding scanning address space that is "empty" or only accepts packets from "known" addresses. If you look at the distribution of military-related address ranges, you can see where you might want to steer clear of. Let the military do its job and keep yourself out of trouble.
References
[IANA] Internet Assigned Numbers Authority, "Internet Protocol in v4 Address Space", December, 2001.
[RFC 792] Postel, J., "Internet Control Message Protocol", September, 1981.
[RFC 1466] Gerich, E., "Guidelines for Management of IP Address Space", May, 1993.
[RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", September, 1993.
[RFC 1519] Fuller, V. et al. "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", September, 1993.
[RFC 1700] Reynolds, J. K., and J. Postel, "ASSIGNED NUMBERS", October, 1994.
[RFC 1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", June, 1995.
[RFC 1918] Rekhter, Y. et al, "Address Allocation for Private Internets", February, 1996.
[RFC 1930] Hawkinson, J., "Guidelines for creation, selection, and registration of an Autonomous System (AS)", March, 1996.Acknowledgements: Thanks to Mirko Zorz for editorial suggestions.
Copyright © 2002 Global Services
Original publication: June 16, 2002Back to Net Census