ABSTRACT
The Internet as we currently recognise it was institutionally established in 1983 when all hosts connected to the then ARPANET were required to have adopted the relatively new Transmission Control Protocol/Internet Protocol (TCP/IP) technologies. Thirteen years later, in 1996, a replacement standard was established for the IP protocol, to resolve key anticipated technical problems. More than 20 years later, those technical problems have indeed arisen, and yet the “new” protocol, IPv6, is still not widely deployed. This paper explores technical and institutional aspects of this case in order to examine how the evolving contexts of infrastructure use may turn technological solutions into infrastructural problems.
Acknowledgments
I am grateful to Sandra Braman, Kevin Driscoll, Eric Monteiro, Laura Watts and the Internet Histories editors and reviewers for their contributions to the development of this paper. Aspects of this work have been supported by the National Science Foundation through award 1556091. The groundwork for this article was laid during a sabbatical hosted by Microsoft Research New England.
Disclosure statement
No potential conflict of interest was reported by the author.
Notes
1. In accordance with house style, I distinguish throughout this article between “internet” with a lower-case initial as a generic term and “the Internet”, with an initial capital, to indicate the global public Internet.
2. Two other protocols, the Internet Control Message Protocol (ICMP) and User Datagram Protocol (UDP), round out the set of core internet protocols. Both UDP and TCP rely upon IP to transmit their information. ICMP is independent but constitutes a tiny percentage of traffic in most cases. Due to the dominance of TCP and IP, “TCP/IP” often functions as a shorthand label for the core protocol set.
3. It should be noted that, in the face of impending address exhaustion, some mechanisms for recycling of previously-allocated addresses were implemented, and some institutions, such as Stanford University, gave up their early large allocations in return for a series of smaller allocations that could be more efficiently deployed. These stopgap measures helped, but were never imagined to resolve the underlying problems.
4. Not to be confused with the Session Initiation Protocol, also abbreviated SIP, and developed with input from some of the same designers.
5. RFC 1883 specified the core protocol; at the same time, RFCs 1884, 1885 and 1886, published alongside 1883, set out adaptations to protocols such as ICMP and DNS necessary for the support of IPv6. The IPv6 specifications have been repeatedly updated, and RFC 1883 is formally obsolete, but it is my reference point here for its place in the timeline rather than for its technical currency.
7. See, for example, https://www.google.com/intl/en/ipv6/statistics.html, https://www.mrp.net/ipv6_survey/ and https://www.potaroo.net/stats/1x1/, in addition to the academic references cited here.
8. See note [7].
9. A “tunnel” is a mechanism that allows packets from one network to be encapsulated within a connection on a different network. In this case, two hosts might use IPv4 to establish a network connection, and then send IPv6 packets over it, communicating as if they were able to exchange IPv6 packets directly. In this way, an IPv6 connection can be established even when IPv6 is not being transmitted directly on the underlying network.
10. Confusingly, there are two operating systems by this name that are connected to this topic. Apple's “iOS” is the operating system that powers iPhones and iPads; prior to 2010, it was called “iPhone OS”. Cisco, a major vendor of network switches, powers those switches with an operating system called IOS. While the topic of Cisco's operating system could be relevant, my references to iOS in this article are to Apple's operating system.
12. A third private block is reserved at 172.16.x.x – 172.31.x.x, although it is rarely used by residential NAT devices.
13. While NAT has been traditionally deployed at the network edge in this way, a more recent development, so-called “Carrier-grade NAT” or NAT444, is a NAT-based mechanism, is deployed by service providers inside the network infrastructure. I do not follow this development here since it does not directly impinge upon my argument, except to the degree that it makes measurements of the IPv4 Internet more ambiguous again (Livadariu, Benson, Elmokashfi, Dainotti, & Dhamdhere, Citation2018).
Additional information
Funding
Notes on contributors
Paul Dourish
Paul Dourish is Chancellor's Professor of Informatics and Associate Dean for Research in the Donald Bren School of Information and Computer Sciences at UC Irvine, with courtesy appointments in Anthropology and Computer Science. His research in science and technology studies and human–computer interaction examines the social and cultural contexts of information technology development. His most recent book is “The Stuff of Bits: An Essay on the Materialities of Information” (MIT Press, 2017).