Building

A Brief History of the IPv4 Address Space

This is meant to be the first part of a 3-part series discussing the space & types of IP addresses, with a particular focus on what has changed between IPv4 and IPv6. In this first post I’ll take the audience through a historical tour of some developments within the IPv4 address space.

In a second part I’ll discuss the properties of different types of addresses from a routing and from a security perspective, both in the IPv4 and in the IPv6 space. In the third part we’ll look at the implications of deploying IPv6 in certain networks based on those differences, e.g. “how to handle ACLs and IP address based log analysis approaches in a dual-stack network where systems have one RFC 1918 IPv4 address and multiple IPv6 GUAs?” (for specific reasons the latter two parts might be published on another medium though). In any case let’s start with a brief history of IPv4. The goal here is to understand how we got to the state that we have today.

Initially the ARPANET which connected four systems in 1969 and which was the nucleus of what then became the Internet used a protocol called Network Control Protocol (NCP). While NCP already facilitated the development of higher-level applications such as file transfer (RFC 354, 1972 – in this post I’ll often add dates when referencing RFCs 😉 and e-mail (RFC 524, 1973), it lacked capabilities of “internetworking” (connecting *networks* of different sizes & numbers of hosts as opposed to connecting just a specific set of computers which were called “Interface Message Processors” [IMPs] at the time).

Hence in 1974 Vinton G. “Vint” Cerf and Robert E. Kahn outlined a new “Protocol for Packet Network Communication” (in this paper). This protocol, called TCP, provided both forwarding (later “IP”) and transport (later “TCP”) functions and it already contained the notion of an address (obviously called “TCP address” then) with a length of 24 bits. 8 bits were supposed to be used “for network identification” as 256 seemed a reasonable number of networks for the foreseeable future 😉. In the following this (one protocol) was split into two protocols one of which (“IP”) was mainly discussed in a series of documents called Internet Experiment Notes (IENs).

IEN 54 (Sep 1978) is titled “The Internetwork Protocol Specification. Version 4” and became the basis for RFC 760, the initial RFC describing IPv4 (at the same time this was IEN 128), that mentions an “8 bit network number, which is the first octet of the address” (RFC 760, sect. 3.2).

While RFC 760 does not contain a discussion which entity actually manages or assigns such addresses (namely those 8-bit network numbers) apparently Jon Postel maintained an initial list of the network numbers used at the time in the IEN 115 which was then published as RFC 796 “ADDRESS MAPPINGS” (Sep 1981) that also already contains a notion of “Class A, B and C” networks. According to this interesting “History of the Internet” article from APNIC “maintaining a list of assigned network addresses was carried out voluntarily by Jon Postel, using (according to legend) a paper notebook”. While probably referencing a later period of time this post on the NANOG mailing list somewhat echoes the style of the times when stating:
“there weren’t any contracts or other written agreements, it was all informal and based on folks doing the right thing, without fully agreed upon terms of what the ‘right thing’ was (other than ‘for the good of the Internet’ I suppose)”.

As the Internet slowly grew a more structured way to manage the address space was needed which led to the creation of the IANA, (afaik) initially mentioned in RFC 1083 “IAB OFFICIAL PROTOCOL STANDARDS” (Dec 1988). As the “Internet Registry” (IR) function within the “IANA” function was awarded by contract to SRI International located at Menlo Park/Stanford University (where Jon Postel worked) it was essentially still him taking care, just no longer by means of his paper notebook ;-). Instead apparently a flat text file was used (see below) which was regularly published in respective RFCs titled “Assigned Numbers” (the earliest one that I could identify is RFC 762 from Jan 1980).

Looking at one of those, that is RFC 943 from April 1985, some networks can already be identified which can also be found in the today’s “IANA IPv4 Address Space Registry”, like 12.0.0.0 being assigned to “ATT, Bell Labs” or 44.0.0.0 being assigned to “Amateur Radio Experiment Net” (subject of a fierce debate recently after 44.192.0.0/10 was sold to Amazon). Of interest for our discussion is further that RFC 990 mentions “Special Addresses” like “Internet Address” 000 being “Reserved” and “Internet Address” 127 constituting “Loopback” (we’ll get back to “Special Addresses” in more detail in the second part). Also RFC 1060 from March 1990, describes “Class D” (“INTERNET MULTICAST ADDRESSES”) and “Class E” (for experimental use) addresses.

Publishing the “Assigned Numbers” as RFCs was discontinued at some point but obviously a database existed with network numbers assigned at the respective time. This “network-contacts.txt” shows the list of assigned networks as of (presumably) October 1990 and it contains some networks still present (as “LEGACY” networks) in today’s IANA Registry such as 17.0.0.0 (assigned to Apple) or 53.0.0.0 (assigned to Daimler – I have no idea if the lady with the name “Erdmuthe Paschitta” still works there but from today’s perspective she should probably be given the company’s “Honorary Gold Medal”, if such a thing exists). Btw, that file was found on the “Old Internet Files” archive which is a great resource if you have an interest in this type of things.

So let’s quick summarize where we stand, at the beginning of the 90s:

  • The notion of Class A-E networks is established, incl. Class D for multicast and Class E for experimental use.
  • Quite some “Class A” networks have been assigned to different organizations, in a more or less structured way.
  • Some “reserved” addresses, for special purposes (like 0.0.0.0, 127.0.0.0) have been defined.
  • Addresses are considered to be “globally unique”, administered by a central entity.

The next decade brought two developments which are of particular interest for us and which I’ll hence discuss in the following.

In (about) July 1991 an Internet-Draft (“draft-chiappa-routing”, v01 here) appears which mentions several problems of the at-the-time current system incl. “the accelerating use of the limited number of network numbers and […] the eventual limits of the 32 bit address”. Also in November 1992 the RFC 1380 IESG Deliberations on Routing and Addressing is published which has a dedicated section on “IP Address Exhaustion”. So clearly the issue of IPv4 address space exhaustion was already known in those years! Let’s have a quick look at some mitigation suggestions as of that RFC (we’ll also get back to some of those in the second part):

Most of these strategies found their way into individual RFCs within the next years, including a few which describe some of the most important underlying technologies of today’s IPv4 Internet, namely

  • RFC 1338 Supernetting: an Address Assignment and Aggregation Strategy (June 1992, yes I know: that was even before RFC 1380 ;-), which was the predecessor of RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (Sep 1993)
  • RFC 1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion (May 1992)
  • RFC 1597 Address Allocation for Private Internets (March 1994)
  • RFC 1631 The IP Network Address Translator (NAT), May 1994

Here’s a quick walk-through of some of them & their proposals.

RFC 1335 provided these numbers:

and stated: “Address space exhaustion is one of the most serious and immediate problems that the Internet faces today”. As a solution it was suggested to establish a “Dual Networking Architecture” in which “there are two types of Internet addresses:  Internal addresses and External addresses” (RFC 1335, section “The Scheme”).

In RFC 1597 (which later became the well-known RFC 1918!) the authors introduce a thing called “Private Address Space” (consisting of the netblocks 10.0.0.0–10.255.255.255, 172.16.0.0–172.31.255.255 and 192.168.0.0–192.168.255.255) and they express their hope “that using these methods, significant savings can be made on allocating IP address space.” (well, to quite some extent as we know today ;-).

RFC 1631 reiterates (in May 1994) that the “two most compelling problems facing the IP Internet are IP address depletion and scaling in routing” and proposes “another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains” (RFC 1631, Abstract).

So let’s see where we stand by the end of the 90s

  • The Class A to C networks scheme has been “replaced” by a more flexible scheme called CIDR.
  • There’s a duality of global/public addresses vs. “private addresses”.
  • The private addresses are described in RFCs and, obviously, become part of “special/reserved addresses” (plus some other minor additions to that space, like 198.18.0.0/15 as of RFC 2544).
  • The global addresses are no longer administered by one entity but this is delegated to regional organizations called Regional Internet Registries/RIRs (initially described in RFC 1366, Oct 1992).
  • The RIRs still have quite some address space left and they have procedures how to assign portions of that to parties in need.
  • Private addresses can be used in a flexible manner by enterprises and they also gain popularity in home networks (like broadband subscriber networks).
  • If networks using private addresses want to connect to “the global Internet”, another technology called Network Address Translation, is needed. A respective (but not too detailed) standard has be published.
  • “Another protocol with larger address space” (quote from RFC 1380) is defined. It’s called IPv6.

I won’t cover the 2000s in much detail as from an “IPv4 Address Architecture” perspective not much happened during those years. Still some information bits (like RFC 3927 or RFC 6598) will be added in the next part in which we’ll look at the different areas of the overall IPv4 address space in more detail.

Everybody have a great week,
Enno