Before Private IP Addresses: The Sun Documentation Networks

In the early years of TCP/IP networking, there was no address space officially reserved for private networks. The familiar private ranges—

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

—were not introduced until RFC 1597 in March 1994. They were subsequently retained by RFC 1918, which replaced RFC 1597 in February 1996.

The official procedure

Around 1990, an organisation that wanted to build a properly addressed TCP/IP network was expected to obtain an officially assigned IP network number. This applied not only to networks connected to the Internet but also to independent networks using the IP protocol suite.

The request was made to the Hostmaster at the DDN Network Information Center, operated by SRI International. The DDN NIC performed the day-to-day allocation of IP network numbers and autonomous system numbers as the Internet Registry. This responsibility had been delegated to it by the Internet Assigned Numbers Authority (IANA).

At the time, addresses were assigned according to the classful addressing system. An organisation would normally receive a Class A, Class B, or Class C network, depending on its requirements.

An isolated company network could technically use arbitrary addresses without contacting anyone. Nothing in the software prevented this. Administratively, however, this was unsafe: those addresses might already have been assigned—or might later be assigned—to another organisation. If the private network was eventually connected to the Internet or merged with another network, the overlapping addresses would have to be replaced.

Sun’s documentation addresses

Sun Microsystems documentation used networks such as:

192.9.200.0/24
192.9.201.0/24

in its TCP/IP configuration examples. Example machines had names such as ahaggar, tenere, and timbuktu. One documented router, timbuktu, used 192.9.200.70 on one interface and 192.9.201.10 on another.

These were not addresses reserved for examples or private networking. They were part of real public address space assigned to Sun Microsystems. The July 1990 registry recorded most of the 192.9.0.0/16 range as belonging to Sun.

Because Sun systems and their manuals were widely used, administrators sometimes copied the examples directly into their own isolated networks. Consequently, a number of internal networks came to use Sun’s public addresses as though they were private addresses.

While such a network remained isolated, the duplication was usually invisible. Problems appeared when it later needed Internet connectivity or had to be interconnected with another network. The same address could then refer both to an internal machine and to a machine in Sun’s actual network. Correct routing became impossible without renumbering one of the networks.

The precise scale of this reuse is difficult to establish from contemporary published records. It is better treated as a widely reported operational phenomenon than as a quantitatively documented event. What can be established directly is that Sun’s manuals used the addresses, that the addresses belonged to Sun, and that using assigned public space without authorisation was a recognised source of address conflicts.

Personal recollection: As a student in the early 1990s, I remember encountering internal networks whose administrators had used the IP addresses shown in Sun’s manuals.

The introduction of private address space

RFC 1597 responded to the broader problem by reserving three address blocks that organisations could use without coordinating with IANA or an Internet registry. It also explicitly noted that some enterprises had used address space without receiving an assignment, sometimes choosing addresses already assigned to another enterprise. Connecting such networks could create serious routing problems.

RFC 1918 replaced RFC 1597 in 1996 while retaining the same three private address ranges.

The introduction of private address space changed the recommended practice:

hosts requiring globally routable addresses still needed officially allocated address space;
hosts used only inside an organisation could use the reserved private ranges;
private addresses were not to be routed across the public Internet.

A separate problem remained: what addresses should manuals, books, and technical articles use in examples? The IETF eventually reserved dedicated documentation prefixes, including:

192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

These ranges can be used in published examples without borrowing addresses belonging to real organisations.

What the Sun example illustrates

The Sun documentation networks illustrate a transitional period in Internet history.

The use of real addresses in the manual was understandable: Sun used address space assigned to itself, and no complete set of documentation-only IPv4 prefixes yet existed. Nevertheless, examples that could be copied directly into working configuration files created an operational hazard.

The incident also shows that private addressing was not merely a convenient convention. It solved a genuine coordination problem. Before reserved private ranges existed, an organisation had to choose between obtaining globally unique addresses through the Internet Registry or using arbitrary addresses and accepting the risk of future conflicts.

References

Kirkpatrick, S., Stahl, M., and M. Recker. “RFC 1166: Internet Numbers .” Network Working Group, July 1990.
RFC 1166 lists the DDN Network Information Center at SRI International as the source of current network-number information. It also states that network numbers were assigned both to Internet-connected networks and to independent networks using the IP protocol family. The document records the Sun Microsystems allocation covering the 192.9.200.0/24 and 192.9.201.0/24 networks.
Malkin, G., and A. Marine. “RFC 1325: FYI on Questions and Answers—Answers to Commonly Asked ‘New Internet User’ Questions .” Network Working Group, May 1992.
RFC 1325 states that Internet addresses and autonomous system numbers were assigned by the DDN NIC, that the responsibility had been delegated by IANA, and that the DDN NIC served as the Internet Registry.
Sun Microsystems. “Configuring TCP/IP on the Network .” TCP/IP and Data Communications Administration Guide.
The guide uses the 192.9.200 and 192.9.201 networks in examples involving machines named ahaggar, tenere, and timbuktu.
Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot. “RFC 1597: Address Allocation for Private Internets .” Network Working Group, March 1994.
RFC 1597 introduced the three private IPv4 address ranges. It also describes the problems caused when isolated enterprises use address space that has already been assigned elsewhere.
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear. “RFC 1918: Address Allocation for Private Internets .” Internet Engineering Task Force, February 1996.
RFC 1918 replaced RFC 1597 and retained the private ranges now commonly used in internal IPv4 networks.
Arkko, J., Cotton, M., and L. Vegoda. “RFC 5737: IPv4 Address Blocks Reserved for Documentation .” Internet Engineering Task Force, January 2010.
RFC 5737 reserves three IPv4 prefixes specifically for documentation and examples.