During a break, I was talking with Carlos Martínez, our CTO at LACNIC, about how incredible it would have been to witness the original discussions that shaped IPv6. Carlos shared some anecdotes that few people know outside the IETF: there were several proposals competing to become “the next-generation IP,” and after intense collaborative work, the IETF selected the one we now know as IPv6. That conversation sparked my curiosity and led me to look into those proposals… and, above all, to find out what happened to the mysterious IPv5.
In the late 1970s and throughout the 1980s, the increase in the number of computer networks posed an unprecedented challenge: how to transmit voice and video across Internet infrastructure in real time. IPv4 worked well for data and files, but it wasn’t designed for applications requiring low latency and continuous streaming.
To solve this, a group of researchers from ARPA (the U.S. Department of Defense Advanced Research Projects Agency) and other institutions developed the Internet Stream Protocol. The first version, known as ST, evolved into ST-II and was officially assigned version number 5 in the IP header. This is how IPv5 came to be (IEN 119, RFC 1190, RFC 1819).
- It wasn’t designed to replace IPv4, but rather to coexist in specific environments.
- It didn’t solve the problem of impending address exhaustion.
- It had scalability limitations.
- Its technical complexity hindered adoption beyond pilot environments.
IPv5 was never deployed on the public Internet. It was relegated to labs, academic settings, and experimental testing, eventually earning the nickname “phantom protocol.” Its legacy, however, didn’t disappear entirely: it laid the foundation for Voice over IP (VoIP) technologies, which we use daily to communicate almost everywhere in the world. In a way, the “phantom of IPv5” still haunts us.
The Turning Point: IPv4 Exhaustion
In the early 1990s, the Internet was expanding exponentially. Engineers already knew that IPv4’s 32-bit addresses would run out much sooner than expected, that routing was becoming unsustainable, and that new applications demanded stronger security and better quality of service. On thing was clear: 4.3 billion IPv4 addresses would not be enough to support the future of the network.
In 1991, the IETF responded by creating the IP Next Generation (IPng) working group, tasked with designing a protocol that would not only replace IPv4 but also ensure the Internet’s growth for decades to come. What followed was a true technological race. Between 1992 and 1994, several proposals competed for the title of legitimate successor to IPv4, each with a different approach to address the scalability, interoperability, and performance challenges posed by the Internet of the future.
TUBA – TCP and UDP with Bigger Addresses
One of the most relevant proposals was TUBA (TCP and UDP with Bigger Addresses, RFC 1347). Based on the ISO CLNP protocol, it used 20-byte addresses and allowed TCP and UDP to run over that architecture. Its main advantage was that it leveraged an existing standard that supported much larger address space. However, the complexity of migrating to this protocol and the limited adoption of CLNP outside of OSI environments severely limited its potential.
PIP – The P Internet Protocol
Another proposal was PIP (The P Internet Protocol, RFC 1621), which introduced variable-size addresses. Its main appeal was its extreme flexibility, as address-size could grow as the network evolved, adapting to an uncertain future. However, that same flexibility created serious problems: managing routing became much more complex, and compatibility with existing systems proved more difficult, reducing the likelihood of its adoption.
SIP – Simple Internet Protocol
SIP (Simple Internet Protocol, RFC 1710) proposed a more pragmatic solution. Using 64-bit addresses, it offered a simplified design that facilitated the transition from IPv4, making it an attractive candidate in terms of ease of implementation. However, its limitation was clear: although it doubled the number of addresses allowed by IPv4, it was still insufficient to ensure the long-term expansion of the Internet.
CATNIP – Common Architecture for the Internet
In parallel, CATNIP (Common Architecture for the Internet, RFC 1707) was introduced, which sought to unify multiple network architectures, including IPv4, OSI, and IPX, into a single protocol. Its main strength was interoperability, as it would have allowed for seamless integration between different technologies. However, this ambition also proved to be its greatest weakness: the design became overly complex and cumbersome, making it impractical for global deployment in a rapidly growing network.
IPv6: The Winner of a Technical Battle
The last to emerge was SIPP (Simple Internet Protocol Plus, RFC 1710), an evolution of SIP that introduced 128-bit addresses, header extensions, and long-term support capabilities. With its vast address space and greater scalability potential, it offered a robust solution to sustain the Internet for decades to come. Although it was initially more complex than its competitors, it was considered the most solid alternative. Thus, in July 1994, the IETF selected SIPP as the basis for what we now know as IPv6, also incorporating valuable elements from the other proposals.
What’s Next? IPv7?
Over the past 30 years, the Internet has been the stage for a quiet but crucial race: the evolution of its open protocols. Along the way, IPv5 emerged, an experiment that never reached production but introduced ideas that were ahead of its time, including support for multimedia, initial concepts of reserving resources, and more flexible headers. However, the pressure on IPv4 was growing rapidly, and the specter of address scarcity relegated it to the laboratories.
IPv6 was born out of that urgency and after years of debate and consensus within the IETF. With 3.4 × 10³⁸ or approximately 340 sextillion possible addresses, it opened a virtually infinite horizon for the Internet’s expansion. The leap from IPv4 to IPv6 was far more than a simple change of number. It was the culmination of a protocol that never took off (IPv5), intense technical competition, and the collaborative effort of the IETF community, the open, consensus-driven space where the history of the Internet continues to be written to this day.
But the story doesn’t end there. We should also mention IPv7, documented in RFC 1475 under the name TP/IX (The Next Internet or The P Internet Protocol). Its proposal was ambitious for the time: to expand the address space from 32 to 64 bits. What happened? It fell by the wayside, overshadowed by a more robust and future-proof option: IPv6.
The Internet wasn’t built overnight. It’s the product of discussions, experiments, and collective decisions that leave their mark and shape generations. The next big leap has yet to be written. It will be up to the new generations of engineers to decide what the Internet of tomorrow will look like.
References
Cole, R., Chiappa, N., Callon, R., & Gardner, E. (1992). RFC 1347: TCP and UDP with Bigger Addresses (TUBA): A Simple Proposal for Internet Addressing and Routing . Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc1347/
Ullmann, R. (1993). RFC 1475:TP/IX: The Next Internet. Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc1475/
Francis, P. (1994). RFC 1621: Pip Near-term Architecture. Internet Engineering Task Force. https://doi.org/10.17487/RFC1621
McGovern, M., Ullmann R. (1994). RFC 1707: CATNIP: Common Architecture for the Internet . Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc1707/
Hinden, R. (1994). RFC 1710: Simple Internet Protocol Plus (SIPP). Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc1710/
Deering, S., & Hinden, R. (1995). RFC 1883: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc1883/
Deering, S., & Hinden, R. (1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification . Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc2460/
